Michael has been working in the image processing field for several years, including a couple of years managing and developing large image databases for an Australian government department. He currently works for TOWER Software, who manufacture a world leading EDMS and Records Management package named TRIM. Michael is also the developer of Panda, an open source PDF generation API, as well as a bunch of other Open Source code. Michael has a web site at http://www.stillhq.com. This conference paper is about two things. The main focus of the paper is to discuss how to write useful UDP servers in a common scripting language such as bash. The other, more minor, focus of the paper is to give a brief tutorial on the differences between disconnected and connected sockets. In this paper I assume that you have a working knowledge of both bash scripting and C programming. If you don't then hopefully you'll still get something out of the paper, but you might want to trust me about what the code snippets actually do. It strikes me as logical to start with an extremely brief introduction to UDP. At some points it makes sense to compare this with the alternative, TCP. Both UDP and TCP sit on top of the Internet protocol, which handles all the plumbing of actually getting the data out of the back of the client machine to the server. This is where the similarity ends. UDP is the User Datagram Protocol, and is unreliable. On the other hand, TCP is the Transmission Control Protocol, and is reliable. What is reliability? Well, TCP will hold your hand and ensure for you that every packet you send is received by the other machine. It will also ensure that the packets arrive in the right order. There are also some games played with the choice of initial sequence number to make it harder for man in the middle attacks to be successful. UDP is unreliable, which means it does none of this for you. It is the programmer's responsibility to ensure that all the packets sent arrived, and were in the right order. So why would you ever use UDP? This reliability in TCP comes at a price. That price is performance. Before a TCP connection is established, the following protocol sequence occurs: eqimgtcp-handshake.png So before the two machines can even communicate, they've spent a round trip, and processing time, just setting up the connection (the ACK can be sent at the same time as the first packet, as we don't have to wait for an ACK ACK to come back). UDP, on the other hand, does none of this. A single packet is sent, and it either arrives or it doesn't. Normally the client application will note that a reply was never received after a given timeout, and retransmit the packet. A good example of a common network protocol that uses UDP is the Domain Name System (DNS). UDP is well suited here because the packets are short (they fit in a single datagram) and we therefore don't have to worry about our packets arriving out of order. We also want DNS to be as fast as possible. It should be noted that RFC 1034 Domain names — Concepts and Facilities does specify that TCP can also be used for DNS. In fact, because UDP packets are limited to 512 bytes, TCP has to be used for zone transfers. However, RFC 1035 Domain Names — Implementation and Specificationdoes recommend that normal queries occur via UDP. See the further reading section at the end of the this paper for recommendations of places to read more about UDP, IP, and DNS. By default when a UDP socket is created, it is disconnected. What's a disconnected socket? The short answer is that it isn't associated with any given remote machine. This means that each time we fetch data from the socket we have to use the recvfrom(2) function call: int recvfrom(int s, void *buf, size_t len, int flags, struct sockaddr *from, socklen_t *fromlen); The struct sockaddr argument in this function call is populated with enough information for the program to be able to determine where to send the reply packet. The response needs to be sent with the sendto(2) call: int sendto(int s, const void *msg, size_t len, int flags, const struct sockaddr *to, socklen_t tolen); The sendto function call takes another struct sockaddr argument which specifies where the packet should be sent. The code listing below is an example of how to use the recvfrom and sendto functions. This example is a simple UDP echo server. The program waits on a given port, and whenever it receives data, sends it straight back. code2db/home/opensource/shdns/sockets/disconnected.c Let's have a look at this program running. As we can see from the source code, the program listens on UDP port 1234 (very imaginative). We can use netcat to test the program. First, we need to start the server in a different terminal, this is as simple as running it. netcat rocks. Its a little application which lets you push data to arbitrary port numbers using both UDP and TCP. It can also be used to create very simple servers, because netcat can do all the listening for you. For more information, and download details, checkout http://www.atstake.com/research/tools/network_utilities/. A client interaction with the server looks like this: catnetcat-client.txt Note that the punt! is me hitting control c on netcat. The server output for this session is: catserver.txt There are a couple of things worth noting here. Firstly, the UDP server can handle multiple clients at once in the single process. This is because each packet comes in, and is then responded to — there is no assumption made that packets come from the same machine. This model works well for the single packet communication paradigm. Secondly, since the server simply waits for a packet, responds, and then starts waiting again, the server survives disconnects from the client, it simply waits until a new packet comes along. This paper is really about writing useful UDP servers using scripting languages — specifically bash. In this instance, the disconnected nature of these default UDP sockets causes great pain. This is because there is no trivial way in bash to call recvfrom and sendto. Shell scripts want to be able to use the standard read and write calls, because these languages are intended for file and pipe input output, as opposed to socket traffic. We can demonstrate this by writing a very simple, and probably quite impractical inetd server. inetd, and its fairly common xinetd alternative are super daemons. Their role in the networking food chain is as a way of running programs to process network traffic as demand requires. For example, many rsync servers operate from inetd. What this means is that inetd runs in the background as a daemon waiting for connections from clients to the rsync port. It then starts a new copy of rsync for each of these connections, and rsync processes the traffic (and perhaps responds). Many developers write network servers which are intended to be run by inetd because it simplifies development of the application. inetd handles most of the plumbing for the application. Please bear in mind that inetd and xinetd are very configurable, and this is only a general description. There is a brief discussion on how to configure inetd and xinetd later in this paper. You should refer to the relevant documentation for more information. This is a particularly useful example, because our shell scripts are eventually going to run from inetd, so having an understanding of how it works is opportune. code2db/home/opensource/shdns/sockets/disconnexec.c All this program does is wait on port 1234 until a connection comes in, forks, and the new child process starts executing the server program (in this case cat). This technique relies on the fact that the child process will share the environment of the parent process, including its file handles. These are duplicated to stdin and stdout before the server program starts executing, so that network input goes into stdin, and server output is sent back over the network. This of course doesn't work because the socket is disconnected, so cat's read call will work, but its write call fails because the socket layer doesn't know where to send the response to. The answer to our need to use read and write for our shell scripts is a connected socket. A connected socket is simply a socket which has had the connect(2) function called upon it. When the connect function is called, it simply records which machine the network packet came from, so that the socket layer knows where to send the reply packet when it is output with the write function call. Here's a simple example of a connected socket version of the disconnected echo server above. Note that we now use read and write function calls for all the network input output. code2db/home/opensource/shdns/sockets/connected.c We do cheat a little in this example, there is one recvfrom call. This is used to peek at the data which is waiting on the socket to determine the address to which we will connect. The MSG_PEEK means that the data is not actually removed from the queue of data to be processed by this call. I won't include an example of what this program looks like when it runs, because it looks exactly the same as the disconnected echo server above. You'll recall that a couple of examples ago I showed you the code for a simple inetd server. This example below expands on that so it uses a connected socket. This example will behave just like the hard coded echo server in the first and third examples in this paper (except that the server debugging output doesn't happen any more). code2db/home/opensource/shdns/sockets/connexec.c The two standard inetd implementations that most people use are called inetd and xinetd. inetd doesn't implement a connected socket for the server before starting it, which means that it is effectively impossible to write a standard shell script which processes UDP network traffic using a stock inetd. xinetd however does connect the socket before calling the script. It seems logical to me to include a patch to make inetd behave in the manner that I would like it to. After all, if our goal is as noble as implementing a server in shell script, then surely the operating system should be modified to accommodate us? The package which contains inetd as run on Debian is called netkit. The following is a patch to use connected sockets for UDP and TCP servers. code2db/home/opensource/shdns/netkit.patch A simple example of how to configure inetd to handle our UDP echo server is shown below — the configuration file this line is added to is /etc/inetd.conf. It should be noted that myecho is the name of a service I had to add to /etc/services because inetd insists on all services being listed there... catinetd.txt This service has the following characteristics: The service name is myecho. The listing in /etc/services is: catservices.txt Note that we can't use the name echo for our service for a couple of reasons: it is already defined in /etc/services; it is an internal service which inetd already offers using the normal port number; and we wanted to define a different port number for the service, without breaking things which might use the old /etc/services entry. The socket type is dgram, which is short for datagram, the type of packet that the UDP protocol uses. The protocol is UDP. nowait is used to indicate that one server should be started per packet, instead of waiting for the previous server to exit. This argument should always be nowait for TCP servers. The server runs as root. The server is located at /bin/cat The server should be started with these arguments. Note that the name of the executable is always the first argument. Checkout execve(2) for more details. The same echo service configured with xinetd looks like this: catxinetd-config.txt Again, the service is a dgram using the UDP protocol. xinetd will wait for previous requests to be processed before moving onto the next request. The echo service also runs as root, using cat. Note the difference in the way the server arguments are configured. You should also note that on Red Hat systems, services are often configured within their own configuration files, located in /etc/xinetd.d — this is done to make it easier to add new services during package installation. This paper wouldn't be complete without an example of a UDP shell script to run from inetd or xinetd. Something non-trivial is required here, so I present for your enjoyment shdns, a DNS server implemented in bash shell script. The code for shdns is broken into two components. The first is a simple script which redirects the input packet to a file, so that shdns can move backwards and forwards within the input packet to grab the bits it needs as required. code2db/home/opensource/shdns/shdns-server The other part of the code is the script which actually parses the input DNS UDP packet and responds. Note that this is merely a proof of concept at the moment, it doesn't attempt to implement the entire DNS protocol — there is only enough here to perform a name lookup. code2db/home/opensource/shdns/shdns The shdns implementation strategy is summarized by the following diagram. eqimgshdns-design.png You'll note that the reply to the DNS request is constructed in a temporary file and then sent back to the client. This is because inetd will send the output of each write as its own packet. shdns therefore needs to force all of the reply packet to be written at one time. The only configuration required to run shdns, apart from configuring you inetd or xinetd daemon, is to put a file named lookup in the path pointed at by the variable execpath in the shdns source file. Here's a sample lookup file: catlookup.txt You also need a usleep on your path. I couldn't find a Debian package containing this, so I wrote my own. If you need to install a usleep, then just compile usleep.c with a gcc -o usleep usleep.c, and copy it somewhere on your path. The following is a list of reading I found useful whilst working on this paper. If you're interested in this topic area and want to learn more, then starting with this list might be helpful. A list of DNS related Internet RFCs -- http://www.faqs.org/rfcs/dns-rfcs.html An excellent introduction to DNS, as well as many other protocols -- TCP/IP Illustrated, Volume One: The protocols, by W Richard Stevens, published by Addison-Wesley The Freshmeat page for NetKit -- http://freshmeat.net/projects/netkit/?topic_id=150 The xinetd home page -- http://www.xinetd.org/ The source code for shdns -- http://www.stillhq.com/extracted/shdns/