gawkinet: File /inet/udp

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