connect/read/write vs sendto/recvfrom

[Patrick Coghlan]

We are using sockets with UDP in our application.

The connect() system call binds our port number and sets up the
remote port number and IP address. Most of the time there is
no peer at the other end, but the connect() and first write()
do not return any errors.

What does seem to happen is that a packet arrives at the socket
after doing the write() and the subsequent read() that we perform
returns error #239 - connection refused. We only receive this
error when the remote end is located at a different IP address.

Is the following assumption about what is happening correct:

- there is no connection-related handshaking involved since
UDP is selected as the protocol but the packet is being
returned because it could not be delivered (port number
was not assigned)

If this is the case, I want to just ignore the "connection refused"
error. I don't remember getting this error when we were using
sendto()/recvfrom() but we hadn't tried sending packets to a
different IP address either.

[W. Richard Stevens]

> We are using sockets with UDP in our application.
> The connect() system call binds our port number and sets up the
> remote port number and IP address. Most of the time there is
> no peer at the other end, but the connect() and first write()
> do not return any errors.

Correct. All connect() does on a UDP socket is store the peer's
IP address and port number, then return immediately. All write()
does is package the data into a UDP/IP datagram and queue it for
the interface and return. All's fine up to here, so no error is
returned.

> What does seem to happen is that a packet arrives at the socket
> after doing the write() and the subsequent read() that we perform
> returns error #239 - connection refused. We only receive this
> error when the remote end is located at a different IP address.
>
> Is the following assumption about what is happening correct:
> - there is no connection-related handshaking involved since
> UDP is selected as the protocol but the packet is being
> returned because it could not be delivered (port number
> was not assigned)

Correct. If you used a diagnostic tool such as tcpdump you'd see
that an ICMP port unreachable is returned by the other end. Figure
6.12 of my recent book "TCP/IP Illustrated" (Addison-Wesley) shows
that BSD systems convert this ICMP error into the Unix error
"Connection refused."

> If this is the case, I want to just ignore the "connection refused"
> error. I don't remember getting this error when we were using
> sendto()/recvfrom() but we hadn't tried sending packets to a
> different IP address either.

Depends what you mean by "ignore." The ICMP error tells you that
no process is at the destination IP address with a UDP socket bound to
your destination port. That tells you something. Unless someone then
starts a process at that port, you'll continue receiving that error if
you continue writing to your connected socket.

You won't receive these ICMP errors at all unless you issue a connect().
Welcome to the bizarre world of connected vs. unconnected UDP sockets ...
If you want to see something truly bizarre: if your server is multihomed,
start the server and send a datagram to it from the client, *but* send the
datagram to the "wrong" interface on the server and watch with tcpdump ...

Rich Stevens