gawkinet: Interacting

 
 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.