Transport Interfaces

The application programming interfaces to these protocols also vary. TCP resembles a pipe: at either end you feed in bytes, and at the other end the same bytes come out.

UDP resembles a bucket. You pile your bytes in at one end, pass the bucket, and the other end gets the bucket load of bytes (or not, if the network loses them!).

RDPs are in between. Typically, they provide a bucket style interface, but a sequence of them alternating which way they go.

The most common programming interface to all these protocols is called sockets, or winsock on DOS machines. Some Unix boxes also provide an interface called streams.

• Ports

  All of these protocols make use of an idea called ``ports''. The Internet normally only provides one address for a computer (or one for each of its network attachments at least). If you want to carry on more than one conversation between two computers you need extra detailed addressing (like a little extra set of in and out trays). At the same time, you want to distinguish different kinds of conversation (e.g. terminal access from file transfer). This is achieved by reserving a number of port numbers. Then all transport protocol packets carry the port number of the application in the server/destination field, and some uniquely chosen port number for this particular conversation in the source/client field, when going from the client to the server, and vice versa in the other direction. Well known ports are listed in the Assigned Numbers RFC. We say that a server (or ``daemon'') runs on port so and so'.

• RPC

  Some applications (e.g. WWW) use a wrapper for the transport protocol to make it easier (more natural) to use for application programmers who may not be used to networks. This is called Remote Procedure Call, or RPC. RPC makes a procedure in a program running as a server on the network look like it is available to any other program as a client on another machine. The idea is from Xerox in the late 70s, and is very cute:

  When you call a procedure in any programming language like C, C++, Pascal etc, you wrap up a bunch of data in some parameters, and then the program jumps to the procedure. When the procedure is done, it wraps up any results, and jumps back.

  So if the parameters are put into a packet for the call, and sent to the right server, then the server does its work, puts the results in another packet and returns it to the calling client, you have a Remote Procedure Call. The piece of code between the program and the Transport Protocol that does this is called a stub, and can be automatically built by a smart compiler.

  There are only a couple more tricks required:

  1. Binding - the client has to find the right server

  2. Data Formats - the client and server might be different kinds of machines - say a Pentium and a Sparcserver. Their idea of format for even the simplest thing, say an integer variable, might be very different. So the ``wrapping up'' or stub processing stage must include converting formats to some network agreed standard. This is typically called an External Data Representation protocol.

• Sockets

  Sockets are an API to communications that make a remote program look like it is a file, but a file that you can write things to and read different things back from. This means that many of the programs on DOS and Unix systems that operate on local files can be changed to use a stream or datagram socket and work to a remote system, very simply.