[baruchthescribe]

Reposting my comment from five years ago:

I once had a client where the only port available for me to use on their firewalls was for MQTT (1883) because that's how we were getting sensor data from them. They would not open anything else for us no matter how we implored them so I wrote a live TCP wrapper over MQTT to get around it. It was a local multithreaded TCP daemon that listened for outbound requests on a certain port, wrapped them in MQTT and then published them using a unique topic. The server daemon would detect these topics and unwrap them before forwarding to our server processes. So the client machine thought it was making a live TCP connection to our server but in the middle was a funky invisible MQTT wrapper. It was really elegant once it worked but my goodness was it a pain to debug - a couple of months before I got the whole thing right because of all the blind alleys I went down.

[ericvsmith]

I’ve worked at places where subverting firewall rules like this would get you fired. I now refer to such situations where I’m forced to twiddle my thumbs while no work gets done as “letting the process work”.

[exe34]

I always kick this kind of decision upwards: we can do it this way and break this rule, so I need director level approval, or we can wait until the customer blinks.

[n_plus_1_acc]

Yes. Ask your boss for approval and tell them otherwise nothing will get done.

[ocschwar]

So you basically implemented an MQTT-Sockets protocol. Which you could then use to connect to a WebSockets server on the other side.

[baruchthescribe]

I'm trying to remember the reason we couldn't use MQTT-Sockets. I do remember we couldn't though. Also we could not use Web sockets server side.