CODEWITHSUNDEEP
linuxsockets
Tom Xue
Tom Xue

Reputation: 3355

Can socket client and server on the same computer bind to same port?

In my case, I need to run a socket client and server on the same computer.

The udp socket client needs to bind local port to 1234, and will communicate with a socker server on remote side. While an udp socket server in the same computer needs to bind local port to 1234 as well, and will communicate with a socket client on remote side as well.

Is it feasible? Any potential issue or notice? Thanks!

Upvotes: 1

Views: 1630

Answers (5)

jch
jch

Reputation: 5651

No, this is a limitation of the sockets API, and one that impairs the writing of peer-to-peer applications based on TCP.

In a peer-to-peer application, the natural thing to do is to use a single port for both outgoing and incoming connections. While this model is supported by the TCP protocol, it is not supported by the sockets API — if a socket is listening on port p, then binding an active socket to port p will fail.

The obvious workaround is to use an ephemeral port for outgoing connections (not use bind on active sockets). This causes other issues in some cases, which need to be worked around — see for example the p parameter in the BitTorrent extended handshake in BEP-10.

Upvotes: 1

Jeremy Friesner
Jeremy Friesner

Reputation: 73161

If you are using multicast or broadcast UDP communication, then it often makes sense to bind multiple programs to the same UDP port, and it is possible to do so if you call setsockopt() with the appropriate arguments before calling bind() on it:

  const int trueValue = 1;
  setsockopt(fd, SOL_SOCKET, SO_REUSEADDR, &trueValue, sizeof(trueValue));
#ifdef __APPLE__
  setsockopt(fd, SOL_SOCKET, SO_REUSEPORT, &trueValue, sizeof(trueValue));
#endif

In that scenario, a copy of every multicast/broadcast UDP packet received on the port will be delivered to each of the sockets bound to that port (which is roughly the same behavior you would get if each program was running on a separate machine, and therefore usually what you want)

OTOH, if you are sending only unicast UDP packets (i.e. packets that are intended to go to a single recipient) then it's usually not useful to bind multiple programs to the same port, as each UDP packet you send will be received by exactly one receiving program and with multiple programs listening to the same port, it's unspecified/unpredictable which program that will be. In your case, for example, your client program might send a packet and the server wouldn't receive it because the packet has been queued into the client's socket's buffer instead. So for that case you're better off having the client and server bind to different ports. (Keep in mind that any program that receives a UDP packet can easily find out what port the packet's sender is bound to, by calling recvfrom() to receive the packet and looking at the contents of the address argument afterwards; therefore it should be straightforward for the server to reply to packets sent to it by the client, even if the client uses a completely random/arbitrary UDP port every time it runs. If you tell your client to bind() to port 0, the networking stack will pick a currently-available UDP port for it to bind to)

Upvotes: 1

ddd0ng
ddd0ng

Reputation: 1

Definitely client and server cannot bind to same address. bind() function will return -1 and perror() function would print "address already in use" error message. But why do you need client and server to bind to same port? Usually client would choose a random port to communicate with server, or you can bindto a different port from server.

Upvotes: -1

Meysam
Meysam

Reputation: 728

from man nc:

CLIENT/SERVER MODEL
 It is quite simple to build a very basic client/server model using nc.  On
 one console, start nc listening on a specific port for a connection.  For
 example:

       $ nc -l 1234

 nc is now listening on port 1234 for a connection.  On a second console (or a
 second machine), connect to the machine and port being listened on:

       $ nc 127.0.0.1 1234

Upvotes: 0

wuerzelchen
wuerzelchen

Reputation: 252

What are you using? Language, Framework, Libraries...

In general, the server is listening on the local port. The client usually connects to them and doesn't "block" those. So, from my point of view, there shouldn't be an issue.

Upvotes: 0

Related Questions