Workarounds to mask port usage due to active queue?

[wlandau]

#25 (reply in thread) and #27 (comment) make me really optimistic and excited about using mirai for crew. The one remaining obstacle in my case is still the issue of large port ranges required by the client for the active queue (c.f. #26, 24, #22 (reply in thread)). Knowing what I know about the targets user base, many users of crew will be sharing the client machine and IP address with dozens of colleagues, and so occupying hundreds of ports at a time may consume a sizable fraction of shared resources.

With an active queue, the servers dial directly into the active queue daemon instead of the actual client, right? What if the active queue were to run inside a VM or Docker/Singularity container? Wouldn't that create a whole new IP address and port range without risk of conflicting with other users? Is there a simpler and more platform-independent and idiomatic way to give the active queue daemon complete freedom and flexibility with ports? NAT and port forwarding seem like similar concepts but perhaps not helpful here.

[wlandau]

On the bright side, the real endgame is the cloud. If the client and active queue run in their own instance in a VPC, port usage will not be a problem.

[shikokuchuo]

Good observation. I think both the passive and active queues are going to be valuable. Passive can be used where this is an issue + it is simple and robust. Active can be used when it is merited.

[shikokuchuo]

This is now the definitive answer. Suggestion straight from Garrett D'Amore, author of NNG.

Instead of specifying a TCP URL, specify a Websocket URL starting ws://. As we can append arbitrary paths to ws addresses, suddenly we have no limits on the number of connections over one port!

As of fce31f9, I have implemented auto-incrementing the path numerically so we only need to supply one URL as before e.g.

daemons("ws://:5555", nodes = 4)

Or specify a vector and use something more descriptive:

daemons(c("ws://:5555/cpuserver", "ws://:5555/gpuserver"), nodes = 2)

Apparently what we were previously considering to solve this issue was, quote "similar to the old RPCBIND approach used 30 years ago"!!

[wlandau]

Just tested websockets on my end on different computers on the local network, and it works like a dream!

[shikokuchuo]

All thanks to gdamore! I use nanonext to consume websocket data all the time, but I didn't even know scalability protocols over ws was a thing!

[shikokuchuo]

Still works, but oddly the url is not updated. It is possible to get the port using the 'tcp-bound-port' option, but it makes it a bit unclean if I have to manually handle this to manipulate the URL when using ws. If freePort() works for you then I think that may be best for now.

In that case I will happily use parallelly::freePort().

I have actually added an extra check in de40400 as having an inconsistent API between tcp and ws is rather unsatisfactory. Also it is pretty useless to have a zero port showing when the real port is something else. What this does is if the URL queried has a port of zero (should never be the case), it gets the actual port, disconnects and connects again immediately using this port explicitly.

So please feel free to use the NNG implementation instead of parallelly::freePort().

[wlandau]

Thanks! If I specify multiple ws:// websockets with 0 as the port, will mirai/NNG then assign all those websockets to the same actual port?

[shikokuchuo]

No just specify one URL in that case. It will append /1, /2 etc. to the same random port.

If specifying a vector, it is difficult to reason whether you actually want the same port or not, so it is treated more literally.