系统中的两个不同的 UDP 套接字可以绑定同一个端口吗？

Question

I have an application which uses UDP connection, now when i try to run the app more than once its throwing me an exception

java.net.BindException: Address already in use: Cannot bind

but in my another app, which uses tcp connection, i can open two instance of the same app and its working fine. why this error only with UDP connection?

Edit:

TCP socket:

Socket clientSocket= new Socket(ipAddress, 8000);
Socket clientSocket1= new Socket(ipAddress, 8000);

If i create TCP socket like above,with same port, it is not throwing any error. but if i do this with UDP Socket it throwing me an exception, why?

Answer 1

It has to do with the difference between TCP and UDP. When you create a TCP socket you are creating a synchronous client connection to the port on another machine, and when you connect to an address you actually get a local port on the socket as well. So in your example code the two sockets created might be

clientSocket = localhost:2649 <-> ipAddress:8000
clientSocket1 = localhost:2650 <-> ipAddress:8000

Note that while they remote address is the same, the local address has different ports, which is why this is allowed. So here the local an remote machines can reliably send the data back and forth using the established ports.

For UDP this is not the case (I am assuming you are using DatagramSocket). Since UDP is asynchronous (as opposed to synchronous like TCP), to recieve data you are not creating a binding to another specific machine, so for example if you were to try

DatagramSocket udp1 = new DatagramSocket(8000); // = localhost:8000 <-> ?
DatagramSocket udp2 = new DatagramSocket(8000); // = localhost:8000 <-> ?

the udp socket does not know where the data is coming from so there can not be a unique mapping like TCP, also unlike TCP the port you specify is your machine's port, not a remote machine port .

Another way to think of it when you create a UDP socket it is like creating a TCP server socket. When you create a TCP server socket it is waiting for a connection to come from some machine but that machine is unknown and when you create a TCP server socket the port you specify is a local port:

ServerSocket ss1 = new ServerSocket(8000); // = localhost:8000 <-> ?
ServerSocket ss2 = new ServerSocket(8000); // = localhost:8000 <-> ?

Again like UDP this will create a bind exception because the port is for the local machine and the mappings are no longer unique. But when you accept a connection on a server socket the remote machine comes into play to make the socket unique, just as when you create a Socket to a remote machine:

Socket s1 = ss1.accept();// localhost:8000 <-> remoteIp1:12345
Socket s2 = ss1.accept();// localhost:8000 <-> remoteIp2:54321

Note that although the local address is the same, the remote addresses for the sockets are different, and hence the total mapping (localip:port<->remoteip:port) is now unique.

So in a way you can think of a UDP socket as kind of like a TCP server socket and that is why you have to bind it to a unique port.

Answer 2

Are you sure that the TCP application really does a bind with a non-zero port number? It shouldn't work for TCP either. The purpose of port numbers is to identify which running application instance to route the traffic to; if two applications were to each bind two sockets to the same port number, that routing becomes impossible, which is why it's an error.

Answer 3

You have to set the socket to be shareable, or as it's called, SO_REUSEPORT.

In C or C++ this is done with the setsockopt function. When you bind to a port, then set the SO_REUSEPORT, another process can also bind a socket to the same port number. An example use for this is multi-process applications, using multiple CPU cores to read incoming data as fast as possible. When this is done the traffic is load balanced amongst the processes, or as is more likely the case, the first one to read the data, gets it (With UDP).

With TCP this is only relevant to a new connection coming in. When a new connection comes in, the first process to accept() the connection owns that connection, but the port number is still shared by all the processes who bound to it and new connections are subsequently handed off to the first one who grabs it with accept(). It makes no sense to share READING from a TCP socket (though multi-threaded apps can do this) as the data is coming in as a stream with no record delimiters, so having multiple readers read it is just, well, an analogy would be, multiple people reading the same book and tearing out the pages as they read them. You'd be left with each reader having an incoherent mess.