Can two applications listen to the same port?

Question

Can two applications on the same machine bind to the same port and IP address? Taking it a step further, can one app listen to requests coming from a certain IP and the other to another remote IP? I know I can have one application that starts off two threads (or forks) to have similar behavior, but can two applications that have nothing in common do the same?

Kirkuk

For a good detailed answer on reusing addresses/ports with multiple sockets: #14389206 – Blakey

A port can be shared between several processes. For example, Node.js via built-in cluster module can share a listening socket, so forked processes of the cluster can directly accept connections from clients utilizing all CPU cores to make workload balanced. nodejs.org/api/cluster.html – Dogvane

Answer 1

The answer differs depending on what OS is being considered. In general though:

For TCP, no. You can only have one application listening on the same port at one time. Now if you had 2 network cards, you could have one application listen on the first IP and the second one on the second IP using the same port number.

For UDP (Multicasts), multiple applications can subscribe to the same port.

Edit: Since Linux Kernel 3.9 and later, support for multiple applications listening to the same port was added using the SO_REUSEPORT option. More information is available at this lwn.net article.

Magnetize

"one application listening on a single port" that's the reason why ports exist -- to allow multiple applications to share the network without conflicts. – Crural

One listener per port per IP address. Adding another network interface is a way to get a second IP address. Your platform probably supports virtual interfaces which is another way to get two IP addresses with one physical network card. – Fiddlededee

Although I was of the same opinion until now, it turns out I was able to bind two different processes to same ip and TCP port! This is possible if you set ServerSocket.setReuseAddress(true) in Java before binding to it. Really unexpected behaviour. – Hindrance

@Hindrance also note Java bug 7179799 where this can happen on Windows with multiple versions of Java. – Christianize

@Eugen, Chris Dail, If a TCP app is using a port, there's no guarantee that another app can not also listen/interact on the same port? In other words, if apache (httpd) is listening on port 80, this does not guarantee that some other malicious app will not listen/interact on port 80? And what about with UDP? Can a malicious app intercept UDP communication of another app using the same port? – Pridemore

The question is about linux, but the answer here is pretty thorough and covers others: https://mcmap.net/q/53582/-how-do-so_reuseaddr-and-so_reuseport-differ – Felicefelicia

(1) The actual meaning of your answer is 'For TCP, yes, provided ...' (2) Multicast is not a precondition for UDP port sharing, but SO_REUSEADDR is. – Amandy

For UDP (Multicasts), multiple applications can subscribe to the same port. If one packet has arrived from client, which application receive it? – Obstacle

Hi everyone, what can I read to dig deeper into this topic? Specifically, I want to understand the 'why' behind what @JohnM said: "One listener per port per IP address". – Frankhouse

@Chris, This answer is misleading and should be edited / deleted. – Sisyphus

@Chris and what happens if two apps are listening on the same port, I have a memdump where 9 local addresses are listening on the same port – Spall

2 network cards are not necessary to have 2 IP addresses. Simply have the kernel listen on a second IP address on that interface. You can have as many IP addresses as you want on an interface. – Jenifer

Did you have a source about this? I need to my article. Thanks – Chariot

Windows has port sharing features. Under Linux you can (unsafely) share the fd (socket descriptor/handle) but it won't really function as a shared port would under Windows. This answer is not entirely true except according to strict "BSD Sockets" which does not define any such sharing. In the case where multiple processes are listening on the same port, when configured to do so, the most-recent listener is the one which receives connections/clients/sockets. – Baeyer

This is not exactly true, see JNewton's answer. – Legalism

@YangJuven what is the answer to your question? – Tertial

@YangJuven All sockets will receive a multicast packet. For unicast UDP, the behavior depends on the OS. – Administration

This is not correct! You can have two applications running on the same port as long as the PATHS to those applications are different. – Obscuration

Answer 2

Yes (for TCP) you can have two programs listen on the same socket, if the programs are designed to do so. When the socket is created by the first program, make sure the SO_REUSEADDR option is set on the socket before you bind(). However, this may not be what you want. What this does is an incoming TCP connection will be directed to one of the programs, not both, so it does not duplicate the connection, it just allows two programs to service the incoming request. For example, web servers will have multiple processes all listening on port 80, and the O/S sends a new connection to the process that is ready to accept new connections.

SO_REUSEADDR

Allows other sockets to bind() to this port, unless there is an active listening socket bound to the port already. This enables you to get around those "Address already in use" error messages when you try to restart your server after a crash.

Mckissick

TCP + UDP now works (given a new enough kernel). See the link I added to the answer. – Obliquely

This answer is not correct unless all the sockets are bound to distinct IP addresses none of which is INADDR_ANY, or unless you are on Windows, where the result is undefined. – Amandy

Can you expand on how the data goes to a specific app on the same port? Are there any security concerns to think about when apps use SO_REUSEADDR or SO_REUSEPORT? – Pridemore

@EJP Can you also take a look at my previous comment? – Pridemore

If a client connects to IP1:port it talks to the socket which is listening at IO1:port. Similarly for IP2:port etc. – Amandy

NOTE you said that initially TWO Programs can LISTEN but cannot start a process/separate memory address rite? the question is about starting or having two processes in a Same Port which is not possible at all.. HENCE a service can be started on a port and one or more clients can listen to the service to that port... – Richers

@Gokul Servers listen. Clients connect. Don't confuse the issue by misusing standard terminology. – Amandy

@EJP yes.. and hopefully I want an answer for the difference between Listening and Connecting.. May be i was bit confused .. am sorry... I thought that when two programs listen to a port then the connectivity will be confused for the client to which program is serving at the port!!!.. is it so? am sorry if i asked wrong.. – Richers

SO_REUSEADDR certainly doesn't let you have two TCP sockets in listening state at the same time, at least on Unix. It's meant to get around the TIME_WAIT state: unixguide.net/network/socketfaq/4.5.shtml . It might work on Windows, but you're not guaranteed that the request will reach the right server anyway). – Natty

@GokulEzhumalai The difference is that servers listen and clients connect. I've already said that. – Amandy

Yes, thank you, I had no idea what was going on until I realized that two instances of apache was running one with the old and one with the new configuration and I was receiving random responses. – Legalism

Answer 3

Yes.

1. Multiple listening TCP sockets, all bound to the same port, can co-exist, provided they are all bound to different local IP addresses. Clients can connect to whichever one they need to. This excludes 0.0.0.0 (INADDR_ANY).

2. Multiple accepted sockets can co-exist, all accepted from the same listening socket, all showing the same local port number as the listening socket.

3. Multiple UDP sockets all bound to the same port can all co-exist provided either the same condition as at (1) or they have all had the SO_REUSEADDR option set before binding.

4. TCP ports and UDP ports occupy different namespaces, so the use of a port for TCP does not preclude its use for UDP, and vice versa.

Reference: Stevens & Wright, TCP/IP Illustrated, Volume II.

Amandy

have you a link at hand? The opportunity of TCP-UDP coexistence is my very question. Thanks in advance:) – Rento

@Rento Just try it. That's all the proof you really need. My citation is Stevens & Wright: you can't get much better than that. – Amandy

Thanks for the response, I need to read even more attentive. You already wrote that UDP and TCP can coexist. – Rento

Answer 4

In principle, no.

It's not written in stone; but it's the way all APIs are written: the app opens a port, gets a handle to it, and the OS notifies it (via that handle) when a client connection (or a packet in UDP case) arrives.

If the OS allowed two apps to open the same port, how would it know which one to notify?

But... there are ways around it:

1. As Jed noted, you could write a 'master' process, which would be the only one that really listens on the port and notifies others, using any logic it wants to separate client requests.
   • On Linux and BSD (at least) you can set up 'remapping' rules that redirect packets from the 'visible' port to different ones (where the apps are listening), according to any network related criteria (maybe network of origin, or some simple forms of load balancing).

Goldman

iptables -m statistic --mode random --probability 0.5 is fun. – Sastruga

What exactly signify "Opens a port"? I understand the sentence but do you know what exactly the system do when it open a port and handle it? I know that when you want to open a port with TCP, you get a stream and that stream is your connection with the remote but I search on the web and don't found a very good explanation. – Marjorymarjy

@Samuel: opening a port (in server mode) means getting a file descriptor, and when the system gets a SYN packet to that port number, responds with SYN+ACK and generates an event on the associated file descriptor. the application responds to that event with an accept() call, which creates a new file descriptor associated to the specific stream, leaving the original server descriptor free to get new connections from clients – Goldman

This answer cannot be considered correct. It entirely overlooks the existence of both SO_REUSEADDR and SO_REUSEPORT. – Amandy

@Goldman No it doesn't. Opening a port from the point of view of the server application occurs when you bind the listening socket, or rather bind the socket you are about to listen() on. More probably the question is about opening it in the firewall. Far too many errors here, and all uncorrected in 7 years. Answer also omits the case of binding to different local address with the same port number. It is in fact totally incorrect. – Amandy

Answer 5

Yes Definitely. As far as i remember From kernel version 3.9 (Not sure on the version) onwards support for the SO_REUSEPORT was introduced. SO_RESUEPORT allows binding to the exact same port and address, As long as the first server sets this option before binding its socket.

It works for both TCP and UDP. Refer to the link for more details: SO_REUSEPORT

Hybridism

Totally true. If it was not true, how Wireshark could work? – Irwin

@Irwin Wireshark doesn't listen to ports. It operates at the packet level. – Amandy

Oh, that would make sense. Anyway, listening two ports by 2 apps is surely possible. – Irwin

Thanks, would never know why the http server lib I'm using is allowing binding same ports if it's not this answer. – Scion

I understand that two applications/processes can listen on the same combination. But then when a request arrives how does the OS bifurcate between which process should handle the request? – Ablepsia

Answer 6

No. Only one application can bind to a port at a time, and behavior if the bind is forced is indeterminate.

With multicast sockets -- which sound like nowhere near what you want -- more than one application can bind to a port as long as SO_REUSEADDR is set in each socket's options.

You could accomplish this by writing a "master" process, which accepts and processes all connections, then hands them off to your two applications who need to listen on the same port. This is the approach that Web servers and such take, since many processes need to listen to 80.

Beyond this, we're getting into specifics -- you tagged both TCP and UDP, which is it? Also, what platform?

Sastruga

both are of interest to me. The platform is windows, but if the answer is different for Linux, it would be nice to know – Kirkuk

There is no such thing a s a multicast socket. There are UDP sockets. Multicast is not a precondition for SO_REUSEADDR. – Amandy

How about http? The port is 80 by default. But I can open many. – Bolt

Answer 7

You can have one application listening on one port for one network interface. Therefore you could have:

1. httpd listening on remotely accessible interface, e.g. 192.168.1.1:80
2. another daemon listening on 127.0.0.1:80

Sample use case could be to use httpd as a load balancer or a proxy.

Guarneri

Answer 8

When you create a TCP connection, you ask to connect to a specific TCP address, which is a combination of an IP address (v4 or v6, depending on the protocol you're using) and a port.

When a server listens for connections, it can inform the kernel that it would like to listen to a specific IP address and port, i.e., one TCP address, or on the same port on each of the host's IP addresses (usually specified with IP address 0.0.0.0), which is effectively listening on a lot of different "TCP addresses" (e.g., 192.168.1.10:8000, 127.0.0.1:8000, etc.)

No, you can't have two applications listening on the same "TCP address," because when a message comes in, how would the kernel know to which application to give the message?

However, you in most operating systems you can set up several IP addresses on a single interface (e.g., if you have 192.168.1.10 on an interface, you could also set up 192.168.1.11, if nobody else on the network is using it), and in those cases you could have separate applications listening on port 8000 on each of those two IP addresses.

Taveras

Answer 9

Just to share what @jnewton mentioned. I started an nginx and an embedded tomcat process on my mac. I can see both process runninng at 8080.

LT<XXXX>-MAC:~ b0<XXX>$ sudo netstat -anp tcp | grep LISTEN
tcp46      0      0  *.8080                 *.*                    LISTEN     
tcp4       0      0  *.8080                 *.*                    LISTEN   

Depredation

Answer 10

Another way is use a program listening in one port that analyses the kind of traffic (ssh, https, etc) it redirects internally to another port on which the "real" service is listening.

For example, for Linux, sslh: https://github.com/yrutschle/sslh

Lanielanier

Is there such a program on windows? I need to have both my local IIS server and ActiveMQ broker listen on port 443 – Stauder

Answer 11

If at least one of the remote IPs is already known, static and dedicated to talk only to one of your apps, you may use iptables rule (table nat, chain PREROUTING) to redirect incomming traffic from this address to "shared" local port to any other port where the appropriate application actually listen.

Spoondrift

Answer 12

Yes.

From this article:
https://lwn.net/Articles/542629/

The new socket option allows multiple sockets on the same host to bind to the same port

Space

Nice link, however do not this line written there - The SO_REUSEPORT option is non-standard – Helprin

Answer 13

Yes and no. Only one application can actively listen on a port. But that application can bequeath its connection to another process. So you could have multiple processes working on the same port.

Complacency

@trusktr, I think he meant this – Congress

Answer 14

You can make two applications listen for the same port on the same network interface.

There can only be one listening socket for the specified network interface and port, but that socket can be shared between several applications.

If you have a listening socket in an application process and you fork that process, the socket will be inherited, so technically there will be now two processes listening the same port.

Congress

Answer 15

I have tried the following, with socat:

socat TCP-L:8080,fork,reuseaddr -

And even though I have not made a connection to the socket, I cannot listen twice on the same port, in spite of the reuseaddr option.

I get this message (which I expected before):

2016/02/23 09:56:49 socat[2667] E bind(5, {AF=2 0.0.0.0:8080}, 16): Address already in use

Kudu

Answer 16

If by applications you mean multiple processes then yes but generally NO. For example Apache server runs multiple processes on same port (generally 80).It's done by designating one of the process to actually bind to the port and then use that process to do handovers to various processes which are accepting connections.

Pyrology

Answer 17

Short answer:

Going by the answer given here. You can have two applications listening on the same IP address, and port number, so long one of the port is a UDP port, while other is a TCP port.

Explanation:

The concept of port is relevant on the transport layer of the TCP/IP stack, thus as long as you are using different transport layer protocols of the stack, you can have multiple processes listening on the same <ip-address>:<port> combination.

One doubt that people have is if two applications are running on the same <ip-address>:<port> combination, how will a client running on a remote machine distinguish between the two? If you look at the IP layer packet header (https://en.wikipedia.org/wiki/IPv4#Header), you will see that bits 72 to 79 are used for defining protocol, this is how the distinction can be made.

If however you want to have two applications on same TCP <ip-address>:<port> combination, then the answer is no (An interesting exercise will be launch two VMs, give them same IP address, but different MAC addresses, and see what happens - you will notice that some times VM1 will get packets, and other times VM2 will get packets - depending on ARP cache refresh).

I feel that by making two applications run on the same <op-address>:<port> you want to achieve some kind of load balancing. For this you can run the applications on different ports, and write IP table rules to bifurcate the traffic between them.

Also see @user6169806's answer.

Helprin