Internet Applications

Hey let's write some apps that use the Internet!

Those Layers Again

So what's an app, or application? Generally, it's something that does something for people, without any concern for how data is actually run between the hosts. In the traditional 5-layer view, anything above TCP is considered application-level communication

Application

Transport (e.g. TCP, UDP)

Internet (e.g. IP)

Network Interface (e.g. ARP)

Physical

Transport software just routes packets between applications; it doesn't care what the application data is.

Examples of Applications

Here are some distributed applications that require well-defined application level protocols

• Sending and receiving email
• Browsing information archives
• Copying files between computers
• Playing interactive games

Most applications not only shield users from transport details, they shield users from protocol "numbers." They define symbolic names for resources and services, etc.

• Example: www.ticketmaster.com => 209.104.46.141
• Example: ssh => 22

There's a wide variety in the complexity of applications

• Network "Services" provided by
  • Name servers
  • Configuration servers
  • Mail gateways, transfer agents and relays
  • File and print servers
• Network "Applications", for example
  • WWW (via HTTP, RFC 1945, 2616)
  • File Transfer (via FTP, RFC 959)
  • Sending mail (via SMTP, RFC 2821)
  • Retrieving mail (via POP, RFC 1939 or IMAP, RFC 2060)
  • News (via NNTP, RFC 977)
  • Gopher (via the Internet Gopher Protocol, RFC 1436)
  • WAIS
  • Archie
  • Telnet (RFC 854)
  • Secure Shell

Writing Internet Applications

Virtually every Internet application uses the client-server paradigm of communication.

• Server — the application (not the machine) that passively waits for contact.
• Client — application (not the machine) that actively initiates contact.

Once connection is established, the two applications can talk back and forth any way they want.

In order to "fairly" handle multiple simultaneous clients, a server should

• Be multithreaded,
• Fork copies of itself, OR
• Be event-driven.

Some Existing Internet Applications

Some of these are pretty old-school and might not exist on your machine, but the RFCs will stay around forever.

Daytime (RFC 867)

Server runs on port 13. When a client connects, the server sends back a string with the current date and time, then immediately closes the connection. (From the RFC: "There is no specific syntax for the daytime. It is recommended that it be limited to the ASCII printing characters, space, carriage return, and line feed. The daytime should be just one line."

Time (RFC 868)

Server runs on port 37. When a client connects, the server sends back a 32-bit time value, then immediately closes the connection. (From the RFC: "The time is the number of seconds since 00:00 (midnight) 1 January 1900 GMT, such that the time 1 is 12:00:01 am on 1 January 1900 GMT; this base will serve until the year 2036."

Quote of the Day (RFC 865)

Server runs on port 17. When a client connects, the server sends back a short message then immediately closes the connection. (From the RFC: "There is no specific syntax for the quote. It is recommended that it be limited to the ASCII printing characters, space, carriage return, and line feed. The quote may be just one or up to several lines, but it should be less than 512 characters."

Active Users (RFC 866)

Server runs on port 11. When a client connects, the server sends back a list of the currently active users then immediately closes the connection. (From the RFC: "There is no specific syntax for the user list. It is recommended that it be limited to the ASCII printing characters, space, carriage return, and line feed. Each user should be listed on a separate line."

Discard (RFC 863)

Server runs on port 9. Send it whatever you want. It won't send back anything. This goes on until the client forcibly closes the connection.

Echo (RFC 862)

Server runs on port 7. Whatever you send it, it sends back. This goes on until the client forcibly closes the connection.

Chargen (RFC 864)

Server runs on port 19. When a client connects, the server sends back data. And keeps sending back data. This goes on until the client forcibly closes the connection. "The data may be anything. It is recommended that a recognizable pattern be used in the data."

Finger (RFC 1288)

Server runs on port 79. The client requests information about a person on the remote machine; the server sends back the information and close the connection.

Domain Name Service - DNS (RFC 1035)

Server runs on port 53. Clients ask the name service questions, usually of the type "what is the ip address for this domain name?" and the server responds with an answer of some sort.

Trivial File Transfer (RFC 1350)

Server runs on port 69 over UDP. It is a zillion times weaker than FTP, but is lightweight and simple. The sender and receiver exchange files packet by packet in lock step, with acknowledgements being part of the protocol itself.

Gopher (RFC 1436)

Server runs on port 70. Clients issue a request (an "item selector") for information and the server sends it back. Sounds a lot like WWW, but the information repositories are much more rigid. Not used much anymore.

Simple Mail Transfer (RFC 2821)

Server runs on port 25. A very simple protocol for sending email.

Mailbox Access with POP3 (RFC 1939)

Server runs on port 110. A simple protocol for managing email.

Internet Message Access Protocol — IMAP (RFC 3501)

Server runs on port 143. A modern alternative to POP3. IMAP clients can stay connected for longer times than POP3 clients, can have multiple clients attached to the same mailbox simultaneously, keep state on the server, fetch partial messages, and do other cool things.

File Transfer - FTP (RFC 959)

Server runs on port 21. Commands and responses are passed back and forth on this port. The transfer of files takes place using port 20. ...

World Wide Web - HTTP (RFC 2616)

Servers usually run on port 80 (clear) or port 443 (secure) but really could run anywhere. Clients request resources via a uniform resource identifier (URI) and the server responds to the request. Request and response structures are quite detailed. The resources can be absolutely anything and are tagged with a MIME type.