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.