Internet and Intranet Protocols and Applications

1. Internet and Intranet Protocols and Applications Lecture 6 Application Protocols: Telnet, FTP February 27, 2002 Joseph Conron Computer Science Department New York University jconron@cs.nyu.edu

2. Telnet • Used for remote login • Follows client/server model • Uses TCP/IP • Interactive application • RFC 854

3. Remote Login • Client application emulates a terminal • two devices • keyboard • display • Server application passes data through to OS as if terminal were local tty (pseudo terminal)

4. Telnet: client/server

5. Telnet: Interactive Application • User sends small messages frequently (key strokes) • Server also sends small messages frequently (character echo) • How to avoid wasteful TCP packets? • Nagel’s Algorithm

6. Digression: Nagle’s Algorithm • When data arrives one byte at a time, send 1st byte • Buffer remaining bytes until 1st byte is Acked • Then send all buffered data • Very good for apps like telnet, bad for some other apps (like X-Windows): why? • Why does Nagle’s algorithm work? • Question: if it’s good to delay sending request, can it help to delay Ack? When?

7. Telnet Network Virtual Terminal (NVT) • Intermediate representation of a generic terminal. • Provides a standard language for communication of terminal control functions. • Defines a 7 bit code for keys and display codes. • Client converts actual key code to NVT code and sends to server. • Client converts NVT display codes to actual display codes and writes to display.

8. Telnet NVT Session

9. Control Functions • TELNET includes support for a series of control functions commonly supported by servers. • This provides a uniform mechanism for communication of (the supported) control functions.

10. Control Functions • Interrupt Process (IP) • suspend/abort process. • Abort Output (AO) • process can complete, but send no more output to user’s terminal. • Are You There (AYT) • check to see if system is still running.

11. More Control Functions • Erase Character (EC) • delete last character sent • typically used to edit keyboard input. • Erase Line (EL) • delete all input in current line.

12. Command Structure • All TELNET commands and data flow through the same TCP connection. • Commands start with a special character called the Interpret as Command escape character (IAC). • The IAC code is 255. • If a 255 is sent as data - it must be followed by another 255.

13. Looking for Commands • Each receiver must look at each byte that arrives and look for IAC. • If IAC is found and the next byte is IAC - a single byte is presented to the application/terminal. • If IAC is followed by any other code - the TELNET layer interprets this as a command.

14. Commands vs Data • Because commands can be embedded in data stream, most implementations use FSM to process input stream(s). • The ability to send commands at any time allows some interesting possiblities, like: • file transfer • emulating buffered terminals like 3270

15. Command Codes • WILL 251 • WON’T 252 • DO 253 • DON’T 254 • IAC 255 • IP 243 • AO 244 • AYT 245 • EC 246 • EL 247

16. NVT: Negotiating Options • All NVTs support a minimal set of capabilities. • But, some applications need more capabilities than the minimal set. How to do this? • The 2 endpoints negotiate a set of mutually acceptable options (character set, echo mode, etc). • The protocol for requesting optional features is well defined in RFC 854. • The set of options is not part of the TELNET protocol. • new terminal features can be incorporated without changing TELNET protocol. • These are defined in separate RFCs

17. NVT: Options • Variety of options can be negotiated at ANY time: • terminal type (e.g. Vt100) • window size • echo (or not) • Command sequence: • IAC <NVT operation> <option> • operation is one of: • WILL, WONT, DO, DONT • Some options require sub-negotiation (we won’t go into this)

18. Option examples • Line mode vs. character mode • echo modes • character set (EBCDIC vs. ASCII)

19. Option Negotiation • Client wants to disable echo, so sends • <IAC> <DON’T><ECHO> • If server agrees, server responds • <IAC> <WON’T><ECHO> • Server can choose option before client asks • <IAC> <WILL><TRANSMIT BINARY> • And client can say NO • <IAC> <DON”T><TRANSMIT BINARY>

20. File Transfer Protocol (FTP) • TCP/IP standard is File Transfer Protocol (FTP) • General purpose protocol • Operating system and hardware independent • Transfers arbitrary files • Accommodates file ownership and access restrictions • Predates TCP/IP; adapted to TCP/IP later

21. File Transfer Protocol (FTP) • client/server model • client: side that initiates transfer (either to/from remote) • server: remote host • ftp: RFC 959 • ftp server: port 21

22. FTP: Issues • Allow transfer of arbitrary files • Accommodate different file types • Convert between heterogeneous systems • Data types • Word lengths • Rules for file names • Provide some security (user login) • Permit Interactive or Batch Operation

23. The FTP Model ------------- |/---------\| || User || -------- ||Interface|<--->| User | |\----^----/| -------- ---------- | | | |/------\| FTP Commands |/----V----\| ||Server|<---------------->| User || || PI || FTP Replies || PI || |\--^---/| |\----^----/| | | | | | | -------- |/--V---\| Data |/----V----\| -------- | File |<--->|Server|<---------------->| User |<--->| File | |System| || DTP || Connection || DTP || |System| -------- |\------/| |\---------/| -------- ---------- ------------- Server-FTP USER-FTP Figure from RFC 959

24. ftp client contacts ftp server at port 21 two parallel TCP connections opened: control: exchange commands, responses between client, server. “out of band control” data: file data to/from server ftp server maintains “state” TCP control connection port 21 TCP data connection port 20 FTP client FTP server FTP: separate control, data connections

25. FTP: Using separate data connections • Separates commands from data • Client can send commands during data transfer • Closed connection indicates end of file • Control connection persists, data connections come and go

26. Sent as ASCII text over control channel USER username PASS password LIST return list of file in current directory RETR filename retrieves (gets) file STOR filename stores (puts) file onto remote host FTP commands

27. FTP return codes • Status code and phrase (as in smtp, http) returned in ASCII over control connection • 331 Username OK, password required • 125 data connection already open; transfer starting • 425 Can’t open data connection • 452 Error writing file

28. Example Protocol Interaction LOCAL COMMANDS BY USER ACTION INVOLVED ftp (host) multics<CR> Connect to host S, port L, establishing control connections. <---- 220 Service ready <CRLF>. username Doe <CR> USER Doe<CRLF>----> <---- 331 User name ok, need password<CRLF>. password mumble <CR> PASS mumble<CRLF>----> <---- 230 User logged in<CRLF>. retrieve (local type) ASCII<CR> (local pathname) test 1 <CR> User-FTP opens local file in ASCII. (for. pathname) test.pl1<CR> RETR test.pl1<CRLF> ----> <---- 150 File status okay; about to open data connection<CRLF>. Server makes data connection to port U. <---- 226 Closing data connection, file transfer successful<CRLF>. type Image<CR> TYPE I<CRLF> ----> <---- 200 Command OK<CRLF> store (local type) image<CR> (local pathname) file dump<CR> User-FTP opens local file in Image. for.pathname) >udd>cn>fd<CR> STOR >udd>cn>fd<CRLF> ----> <---- 550 Access denied<CRLF> terminate QUIT <CRLF> ----> Server closes all connections.

29. TFTP • Trivial File Transfer Protocol (TFTP) - much simpler than FTP • Based on UDP • File transfer only; no directory listing • No authorization • Requires less code than FTP • Often used for bootstrap; e.g., ROM-based diskless system