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!
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)
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.
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.
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
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.
