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