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.
Here are some distributed applications that require well-defined application level protocols
Most applications not only shield users from transport details, they shield users from protocol "numbers." They define symbolic names for resources and services, etc.
www.ticketmaster.com => 209.104.46.141ssh => 22There's a wide variety in the complexity of 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.
A server should generally be multithreaded (or fork several copies of itself) to properly ("fairly") handle multiple simultaneous clients. Servers thus contain code like:
while(true) {
Connection c = waitForConnection();
spawnANewThreadToHandle(c);
}
or
while(true) {
Connection c = waitForConnection();
spawnANewTaskAndSubmitToAThreadPoolToHandle(c);
}
But now we have many clients talking simultaneously to the service which is "running on" a fixed port. How are these distinguished?
When a client's connection request is granted by the server, networking software on the client gets a port for the client to run on. If there are multiple clients on the same host, they will each have different port numbers. The server, then, uses the combination of client IP address + client port number to know exactly which "connection" is being referred to. These connections are normally referred to as sockets.
Example
Not in this class!
Java has plenty of support in its "Core API" for socket-level programming. Code looks much simpler than C, primarily because a lot of functionality can be put into constructors, you deal with method calls and objects rather than operating system calls on relatively untyped chunks of data. Threads are also very easy to work with; support for them is built in.
Here is a capitalization server in Java:
package edu.lmu.cs.networking;
import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.io.PrintWriter;
import java.net.ServerSocket;
import java.net.Socket;
/**
* A server program which accepts requests from clients to
* capitalize strings. When clients connect, a new thread is
* started to handle an interactive dialog in which the client
* sends in a string and the server thread sends back the
* capitalized version of the string.
*
* The program is runs in an infinite loop, so shutdown in platform
* dependent. If you ran it from a console window with the "java"
* interpreter, Ctrl+C generally will shut it down.
*/
public class CapitalizeServer {
/**
* Application method to run the server runs in an infinite loop
* listening on port 9898. When a connection is requested, it
* spawns a new thread to do the servicing and immediately returns
* to listening. The server keeps a unique client number for each
* client that connects just to show interesting logging
* messages. It is certainly not necessary to do this.
*/
public static void main(String[] args) throws Exception {
System.out.println("The capitalization server is running.");
int clientNumber = 0;
ServerSocket listener = new ServerSocket(9898);
try {
while (true) {
new Capitalizer(listener.accept(), clientNumber++).start();
}
} finally {
listener.close();
}
}
/**
* A private thread to handle capitalization requests on a particular
* socket. The client terminates the dialogue by sending a single line
* containing only a period.
*/
private static class Capitalizer extends Thread {
private Socket socket;
private int clientNumber;
public Capitalizer(Socket socket, int clientNumber) {
this.socket = socket;
this.clientNumber = clientNumber;
log("New connection with client# " + clientNumber
+ " at " + socket);
}
/**
* Services this thread's client by first sending the
* client a welcome message then repeatedly reading strings
* and sending back the capitalized version of the string.
*/
public void run() {
try {
// Decorate the streams so we can send characters
// and not just bytes. Ensure output is flushed
// after every newline.
BufferedReader in = new BufferedReader(
new InputStreamReader(socket.getInputStream()));
PrintWriter out =
new PrintWriter(socket.getOutputStream(), true);
// Send a welcome message to the client.
out.println("Hello, you are client #" + clientNumber + ".");
out.println("Enter a line with only a period to quit\n");
// Get messages from the client, line by line; return them
// capitalized
while (true) {
String input = in.readLine();
if (input == null || input.equals(".")) {
break;
}
out.println(input.toUpperCase());
}
} catch (IOException e) {
log("Error handling client# " + clientNumber + ": " + e);
} finally {
try {
socket.close();
} catch (IOException e) {
log("Couldn't close a socket, what's going on?");
}
log("Connection with client# " + clientNumber + " closed");
}
}
/**
* Logs a simple message. In this case we just write the
* message to the server applications standard output.
*/
private void log(String message) {
System.out.println(message);
}
}
}
To access the server, fire up some telnet clients and start talking.
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."
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."
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."
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."
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.
Server runs on port 7. Whatever you send it, it sends back. This goes on until the client forcibly closes the connection.
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."
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.
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.
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.
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.
Server runs on port 25. A very simple protocol for sending email.
Server runs on port 110. A simple protocol for managing email.
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. ...
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.
Server runs on port 119. Used for the reading and writing news articles structured into newsgroups.