Take the 2-minute tour ×

My initial UDP socket is binded to

The first time that I get notified of incoming data by epoll/kqueue, I do recvfrom() and I fill a struct sockaddr called peer_name that contain the peer informations (ip:port).

Then I create a new UPD socket using socket(),

then I bind() this newly created socket to the same ip:port ( than my original socket.

then I connect my newly created socket using connect() to the peer who just sent me something. I have the information in the struct sockaddr called peer_name.

I then add my newly created socket in my epoll/kqueue vector and wait for notification.

I would expect to ONLY receive UDP frame from the peer i'm ""connected to"".

1/ does netstat -a -p udp is suppose to show me the IP:PORT of the peer my newly created socket is ""connected to"" ?

2/ I'm probably doing something wrong since after creating my new socket, this socket receive all incoming UDP packets destinated to the IP:PORT I'm binded to, regardless of the source peer IP:PORT.

I would like to see a working example of what I'm trying to do :) or any hint on what I'm doing wrong.


share|improve this question
add comment

2 Answers


"Does doing a connect() call affect the receive behaviourof the socket? Yes, in two ways. First, only datagrams from your "connected peer" are returned. All others arriving at your port are not delivered to you.

But most importantly, a UDP socket must be connected to receive ICMP errors. Pp. 748-749 of "TCP/IP Illustrated, Volume 2" give all the gory details on why this is so."

share|improve this answer
add comment

connect(2) on a UDP socket just sets the default destination address of the socket (where the data will be sent if you use write(2) or send(2) on the socket). It has no other effect -- you can still send packets to other addresses with sendto(2) or sendmsg(2) and you'll still see packets sent from any address.

So it doesn't really make any sense to open a new socket on the port -- for every packet received, you need to look at the source address to see if it comes from an address you've seen already (and thus belongs to that logical stream) or is a new address (a new logical stream).

share|improve this answer
Just to be sure, I'm talking about the server side. The Idea, is that the new socket will receive all the data from a specific client. So it's why I connect() my new socket to the source client IP:PORT. A socket as a sockname and a peername. The sockname is the ADDR:PORT the socket is binded to, and the peername is the ADDR:PORT the socket is associated to (using connect()) and thus send() knows to who sending the data. getsockname(), getpeername(). –  nicboul Jun 3 '10 at 18:02
@nicboul: Yes. What Chris is pointing out is that connect() on a UDP socket is generally only useful on the client side, where a single socket is only talking to one peer. It is unhelpful on the server side. –  caf Jun 4 '10 at 2:21
@Chris I amy be nit-picking, but I am not sure I agree with your statement. I think the connect has the effect of a remote-addr bind so that you may restrict traffic on that socket to messages from a specific client. I am basing that in an strace nc -4lu $((0x4444)), followed by grep 4444 /proc/net/udp (in a different terminal), before and after the first message is received. nc will not accept messages from other clients. –  nhed Feb 2 '12 at 17:58
@Chris, I agree with @nhed - I have written a simple test app which connects to the first sockaddr it gets back from a blocking recvfrom call; initiating multiple sendto calls from different sockets results in only the first socket's data being received –  Steve Lorimer Jul 10 '12 at 5:12
add comment

Your Answer


