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