Windows: q can listen on same port as other app

Community Support
1

I just found out that q can listen on the same port as another app. For example, one of the processes with a listening socket:
nvcontainer.exe    3180    TCP    LAPTOP    65000    LAPTOP    0    LISTENING                                       
And if I do \p 65000 in a q process, I will see this, together with the above:
q.exe    6568    TCP    LAPTOP    65000    LAPTOP    0    LISTENING                                       

But if I try to do this with two q processes, I get the error about the port already being in use.

There’s more strange behavior if I have a C++ app that uses c.dll to connect to a q process and also tries to open a listening socket. If the C++ app tries to listen on the same port as the q app it connects to, the listen is apparently successful but in tcpview I don’t see a listening connection, instead I see a new connection from the q process to the C++ process. If the C++ app tries to listen on a port that a different q process listens on, the two apps will be listening on the same port. But if the C++ app tries to listen on a non-q app’s port, I get the “already in use” error.

Why is this happening? I would expect that the listen should fail if any app is already using that port, but q seems to contradict this rule.

I’m using 3.5 2017.05.02 on Windows 10.

2

check the interfaces that the two processes are listening on (one can be listening on 127.0.0.1 while the other on 10.1.1.112)

3

You can have two separate processes listening on the same port, so long as they listen on different IP addresses.

So with the latest q releases, you can do this, too:

// Console 1

q -p 127.0.0.1:8000


// Console 2

q -p 10.0.0.248:8000 # assuming 10.0.0.248 is my LAN IP address

On Monday, June 5, 2017 at 8:39:18 PM UTC+8, Péter Györök wrote:

I just found out that q can listen on the same port as another app. For example, one of the processes with a listening socket:
nvcontainer.exe    3180    TCP    LAPTOP    65000    LAPTOP    0    LISTENING                                       
And if I do \p 65000 in a q process, I will see this, together with the above:
q.exe    6568    TCP    LAPTOP    65000    LAPTOP    0    LISTENING                                       

But if I try to do this with two q processes, I get the error about the port already being in use.

There’s more strange behavior if I have a C++ app that uses c.dll to connect to a q process and also tries to open a listening socket. If the C++ app tries to listen on the same port as the q app it connects to, the listen is apparently successful but in tcpview I don’t see a listening connection, instead I see a new connection from the q process to the C++ process. If the C++ app tries to listen on a port that a different q process listens on, the two apps will be listening on the same port. But if the C++ app tries to listen on a non-q app’s port, I get the “already in use” error.

Why is this happening? I would expect that the listen should fail if any app is already using that port, but q seems to contradict this rule.

I’m using 3.5 2017.05.02 on Windows 10.