>Lars Appel writes:
>>
>> At 17:31 13.06.1997 -0700, you wrote:
>> >The BIND function res_send() attempts to connect() and send() to a datagram
>> >socket, something that is documented as unimplemented for MPE.
connect() and
>> >send() should be enhanced to operate against datagram sockets in addition to
>> >stream sockets.
>>
>> I'm not an expert on sockets, but I always was under the impression that UDP
>> or datagram sockets were intended for connection-less communication i.e. kind
>> of fire-and-forget instead of dial-connect-and-chat...
>>
>> Any enlightenment available on this?

The confusion might be in that UDP (SOCK_DGRAM) sockets can be used in one
of two modes: connected and unconnected. The distinction isn't always
mentioned in casual references that compare/contrast TCP/UDP sockets. The
main difference between TCP/UDP being that TCP is a reliable transport
while UDP is not (the other biggie is that different implementations of
UDP differ in how to handle large messages. Some truncate, some do not).

A great reference (where nothing written is casual):

Internetworking with TCP/IP Volume III, Client-Server
Programming and Applications (BSD Socket Version). Comer and Stevens,
Prentice Hall.

To wit, with regard to UDP:

"In connected mode, the client uses the *connect* call to specify a remote
endpoint address (i.e., the server's IP address and protocol port number).
Once it has specified the remote endpoint, the client can send and receive
messages much like a TCP client does. In unconnected mode, the client does
not connect the socket to a specific remote endpoint. Instead, it specifies
the remote destination each time it sends a message. The chief advantage
of connected UDP sockets lies in their convenience for conventional client
software that interacts with only one server at a time: the application
only needs to specify the server once no matter how many datagrams it sends.
The chief advantage of unconnected sockets lies in their flexibility; the
client can wait to decide which server to contact until it has a request
to send. Furthermore, the client can easily send each request to a different
server."

And now, if you really want to learn more than you thought ever existed
in this realm of tcp/ip and sockets, check out this reference:

TCP/IP Illustrated, Volume I
The Protocols, Stevens, Addison Wesley

Regarding DNS, the auther writes:

"UDP or TCP"

"We've mentioned that the well-known port numbers for DNS name servers are
UDP port 53 and TCP port 53. This implies that the DNS supports both UDP
and TCP. But all the examples that we've watched with tcpdump have used
UDP. When is each protocol used and why?
  When the resolver issues a query and the response comes back with the
TC bit set ("truncated") it means the size of the response exceeded 512 bytes,
so only the first 512 bytes were returned by the server. The resolver
normally issues the request again, using TCP. This allows more than 512
bytes to be returned. (Recall our discussion of the maximum UDP datagram
size in Section 11.10.) Since TCP breaks up a stream of user data into what
it calls segments, it can transfer any amount of user data, using multiple
segments.
  Also, when a secondary name server for a domain starts up it performs a
zone transfer from the primary name server for the domain. We also said that
the secondary queries the primary on a regular basis (often every 3 hours)
to see if the primary has had its tables updated, and if so a zone transfer
is performed. Zone transfers are done using TCP, since there is much more
data to transfer than a single query or response.
  Since the DNS primarily use UDP, both the resolver and the name server
must perform their own timeout and retransmission. Also, unlike many other
Internet applications, DNS queries and responses often traverse wide area
networks. The packet loss rate and variability in round-trip times are
normally higher on a WAN than a LAN, increasing the importance of a good
retransmission and timeout algorithm for DNS clients."

Duane Percox ([log in to unmask]  v/415.306.1608 f/415.365.2706)
http://www.qss.com/          http://www.qss.com/qwebs
http://www.qss.com/faq3k     http://www.qss.com/qsdk