gawkinet: File /inet/udp

1 
1 2.1.2.2 '/inet/udp'
1 ...................
1 
1 The server and client programs that use UDP are almost identical to
1 their TCP counterparts; only the PROTOCOL has changed.  As before, it
1 does matter which side starts first.  The receiving side blocks and
1 waits for the sender.  In this case, the receiver/client has to be
1 started first:
1 
1      # Server
1      BEGIN {
1        print strftime() |& "/inet/udp/8888/0/0"
1        close("/inet/udp/8888/0/0")
1      }
1 
1    The receiver is almost identical to the TCP receiver:
1 
1      # Client
1      BEGIN {
1        print "hi!" |& "/inet/udp/0/localhost/8888"
1        "/inet/udp/0/localhost/8888" |& getline
1        print $0
1        close("/inet/udp/0/localhost/8888")
1      }
1 
1    In the case of UDP, the initial 'print' command is the one that
1 actually sends data so that there is a connection.  UDP and "connection"
1 sounds strange to anyone who has learned that UDP is a connectionless
1 protocol.  Here, "connection" means that the 'connect()' system call has
1 completed its work and completed the "association" between a certain
1 socket and an IP address.  Thus there are subtle differences between
1 'connect()' for TCP and UDP; see the man page for details.(1)
1 
1    UDP cannot guarantee that the datagrams at the receiving end will
1 arrive in exactly the same order they were sent.  Some datagrams could
1 be lost, some doubled, and some out of order.  But no overhead is
1 necessary to accomplish this.  This unreliable behavior is good enough
1 for tasks such as data acquisition, logging, and even stateless services
1 like the original versions of NFS.
1 
1    ---------- Footnotes ----------
1 
1    (1) This subtlety is just one of many details that are hidden in the
1 socket API, invisible and intractable for the 'gawk' user.  The
1 developers are currently considering how to rework the network
1 facilities to make them easier to understand and use.
1