# Windows: q can listen on same port as other app

**URL:** <https://forum.kx.com/t/windows-q-can-listen-on-same-port-as-other-app/11546>\
**Category:** Community Support\
**Tags:** kdb-and-q\
**Created:** [June 3, 2017, 10:07pm UTC](https://forum.kx.com/t/windows-q-can-listen-on-same-port-as-other-app/11546 "2017-06-03T22:07:00Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![gyorokpeter1](https://avatars.discourse-cdn.com/v4/letter/g/db5fbb/32.png) [@gyorokpeter1](https://forum.kx.com/u/gyorokpeter1)\
**Post date:** [June 3, 2017, 10:07pm UTC](https://forum.kx.com/t/windows-q-can-listen-on-same-port-as-other-app/11546/1 "2017-06-03T22:07:00Z")

</div>

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&nbsp;&nbsp;&nbsp; 3180&nbsp;&nbsp;&nbsp; TCP&nbsp;&nbsp;&nbsp; LAPTOP&nbsp;&nbsp;&nbsp; 65000&nbsp;&nbsp;&nbsp; LAPTOP&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; LISTENING&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;  
And if I do \p 65000 in a q process, I will see this, together with the above:  
q.exe&nbsp;&nbsp;&nbsp; 6568&nbsp;&nbsp;&nbsp; TCP&nbsp;&nbsp;&nbsp; LAPTOP&nbsp;&nbsp;&nbsp; 65000&nbsp;&nbsp;&nbsp; LAPTOP&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; LISTENING&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;

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.

---

<div class="post-metadata">

**Author:** ![effbiae](https://avatars.discourse-cdn.com/v4/letter/e/ecae2f/32.png) [@effbiae](https://forum.kx.com/u/effbiae)\
**Post date:** [June 6, 2017, 5:25am UTC](https://forum.kx.com/t/windows-q-can-listen-on-same-port-as-other-app/11546/2 "2017-06-06T05:25:00Z")

</div>

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)

---

<div class="post-metadata">

**Author:** ![Flying1](https://avatars.discourse-cdn.com/v4/letter/f/f4b2a3/32.png) [@Flying1](https://forum.kx.com/u/Flying1)\
**Post date:** [June 6, 2017, 10:34am UTC](https://forum.kx.com/t/windows-q-can-listen-on-same-port-as-other-app/11546/3 "2017-06-06T10:34:00Z")

</div>

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&nbsp;&nbsp;&nbsp; 3180&nbsp;&nbsp;&nbsp; TCP&nbsp;&nbsp;&nbsp; LAPTOP&nbsp;&nbsp;&nbsp; 65000&nbsp;&nbsp;&nbsp; LAPTOP&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; LISTENING&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;  
> And if I do \p 65000 in a q process, I will see this, together with the above:  
> q.exe&nbsp;&nbsp;&nbsp; 6568&nbsp;&nbsp;&nbsp; TCP&nbsp;&nbsp;&nbsp; LAPTOP&nbsp;&nbsp;&nbsp; 65000&nbsp;&nbsp;&nbsp; LAPTOP&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; LISTENING&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;
> 
> 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.