2.4 Interacting with a Network Service

The next program makes use of the possibility to really interact with a network service by printing something into the special file. It asks the so-called finger service if a user of the machine is logged in. When testing this program, try to change `localhost' to some other machine name in your local network:

     
     BEGIN {
       NetService = "/inet/tcp/0/localhost/finger"
       print "name" |& NetService
       while ((NetService |& getline) > 0)
         print $0
       close(NetService)
     }
     

After telling the service on the machine which user to look for, the program repeatedly reads lines that come as a reply. When no more lines are coming (because the service has closed the connection), the program also closes the connection. Try replacing "name" with your login name (or the name of someone else logged in). For a list of all users currently logged in, replace name with an empty string ("").

The final close command could be safely deleted from the above script, because the operating system closes any open connection by default when a script reaches the end of execution. In order to avoid portability problems, it is best to always close connections explicitly. With the Linux kernel, for example, proper closing results in flushing of buffers. Letting the close happen by default may result in discarding buffers.

When looking at /etc/services you may have noticed that the `daytime' service is also available with `udp'. In the earlier example, change `tcp' to `udp', and change `finger' to `daytime'. After starting the modified program, you see the expected day and time message. The program then hangs, because it waits for more lines coming from the service. However, they never come. This behavior is a consequence of the differences between TCP and UDP. When using UDP, neither party is automatically informed about the other closing the connection. Continuing to experiment this way reveals many other subtle differences between TCP and UDP. To avoid such trouble, one should always remember the advice Douglas E. Comer and David Stevens give in Volume III of their series Internetworking With TCP (page 14):

When designing client-server applications, beginners are strongly advised to use TCP because it provides reliable, connection-oriented communication. Programs only use UDP if the application protocol handles reliability, the application requires hardware broadcast or multicast, or the application cannot tolerate virtual circuit overhead.