GNU Info

(gawkinet.info)Interacting

---

Next: Setting Up Prev: Troubleshooting Up: Using Networking

---

Enter node , (file) or (file)node

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.