Sign in to follow this  

How come my UDP socket has a separate port for incoming and outgoing?

This topic is 2820 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I am testing UDP on the localhost on Windows. I create the Server Socket it like this
::socket ( AF_INET, SOCK_DGRAM, 0 ) ;

sockaddr_in sockaddr_ino ;
sockaddr_ino.sin_family = AF_INET ;
sockaddr_ino.sin_port = htons ( 5000 ) ;
sockaddr_ino.sin_addr.s_addr = htonl ( INADDR_ANY ) ;
::memset ( & sockaddr_ino.sin_zero, 0, sizeof sockaddr_ino.sin_zero ) ;

::bind ( Socketo, reinterpret_cast<sockaddr *> ( & sockaddr_ino ),
		sizeof sockaddr_ino ) ;



The Client also creates a socket but does not do bind(). The Client successfully sends Packets to 5000. And I use the Clientsockaddr_ino of recvfrom to reply back to the Client. The Server successfully replies to the Client. But then the Clientsockaddr_ino.sin_port in the Client side recvfrom is not 5000, but something like 34835, which means I cannot use the exact same handling Code in the Client. The Packets sent to 34835 are lost, even though they were sent by the Server Socket. Why not design recvfrom to return 5000?

Share this post


Link to post
Share on other sites
Only one process can bind to a port at a time. It is normal for the client to pick a "random" port (typically, you ask your networking API for port 0 and it will give you a random one for you). The server must store the ipaddress/port combination for each client. With NATs, you have no real choice, you cannot depend on the client picking a given port in general.

Share this post


Link to post
Share on other sites
Quote:
Only one process can bind to a port at a time


That's not actually true.

First, the same port may easily be re-used for client ports when the destination is a different IP address than the IP address used the first time.

Second, with the SO_REUSEADDR TCP option, you can bind to the same port even when a previous process is still in waiting state, for listening purposes. The previous process/socket does not need to be dead.

Third, you can also fork() after binding, and have more than one process bound to the same port. This works for listen and accept as well as reading/writing. However, individual ordering between the different sockets bound to the same port (or connection, for read/write) is not guaranteed or well defined. (But for multi-processing accept() servers, it doesn't much matter)

Share this post


Link to post
Share on other sites
I was really talking only about listening sockets, but I think I misinterpreted the original question anyway - I assumed it was the lassic case where the client was forcing a particular port after only skimming the original post. In any case, as you demonstrated it is possible to have a listening socket shared between multiple processes.

Apologies for the incorrect information. [embarrass]

Share this post


Link to post
Share on other sites

This topic is 2820 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this