gawkinet: Interacting

1 
1 2.4 Interacting with a Network Service
1 ======================================
1 
1 The next program makes use of the possibility to really interact with a
1 network service by printing something into the special file.  It asks
1 the so-called 'finger' service if a user of the machine is logged in.
1 When testing this program, try to change 'localhost' to some other
1 machine name in your local network:
1 
1      BEGIN {
1        NetService = "/inet/tcp/0/localhost/finger"
1        print "NAME" |& NetService
1        while ((NetService |& getline) > 0)
1          print $0
1        close(NetService)
1      }
1 
1    After telling the service on the machine which user to look for, the
1 program repeatedly reads lines that come as a reply.  When no more lines
1 are coming (because the service has closed the connection), the program
1 also closes the connection.  Try replacing '"NAME"' with your login name
1 (or the name of someone else logged in).  For a list of all users
1 currently logged in, replace NAME with an empty string ('""').
1 
1    The final 'close()' command could be safely deleted from the above
1 script, because the operating system closes any open connection by
1 default when a script reaches the end of execution.  In order to avoid
1 portability problems, it is best to always close connections explicitly.
1 With the Linux kernel, for example, proper closing results in flushing
1 of buffers.  Letting the close happen by default may result in
1 discarding buffers.
1 
1    When looking at '/etc/services' you may have noticed that the
1 'daytime' service is also available with 'udp'.  In the earlier example,
1 change 'tcp' to 'udp', and change 'finger' to 'daytime'.  After starting
1 the modified program, you see the expected day and time message.  The
1 program then hangs, because it waits for more lines coming from the
1 service.  However, they never come.  This behavior is a consequence of
1 the differences between TCP and UDP. When using UDP, neither party is
1 automatically informed about the other closing the connection.
1 Continuing to experiment this way reveals many other subtle differences
1 between TCP and UDP. To avoid such trouble, one should always remember
1 the advice Douglas E. Comer and David Stevens give in Volume III of
1 their series 'Internetworking With TCP' (page 14):
1 
1      When designing client-server applications, beginners are strongly
1      advised to use TCP because it provides reliable,
1      connection-oriented communication.  Programs only use UDP if the
1      application protocol handles reliability, the application requires
1      hardware broadcast or multicast, or the application cannot tolerate
1      virtual circuit overhead.
1