embedding amqtt in existing http server

[FlorianLudwig]

Food for thought related to this: in my application I'm using aiohttp as the HTTP server for the main application providing a REST API. I then expose real-time updates via MQTT over websockets.

aiohttp supports creation and hosting of websockets. Right now for the user to access MQTT I have three choices:

• bind amqtt server to a separate port, expose that via the firewall and have my application direct the user to the new port (fine for development, not sure about this for production use though)
• bind amqtt server to a separate private port, configure my application's front-end reverse proxy (nginx) to also forward that second port to some URI namespace.
• bind amqtt server to a separate private port, configure some sort of reverse proxy within aiohttp to forward the MQTT/websocket traffic to amqtt.

I'm wondering if that ListenerType enumeration shouldn't have a plugin option. This would require the user write a plug-in that implements the same interface as the tcp and ws listener types. Thus, in my application, I could implement a plug-in that creates a websocket using aiohttp calls and binds it to a path in my server's namespace. I'm thinking in this situation, things like the bind option become optional since bind makes no sense when you're not actually binding to a network socket directly.

Anyway, probably this is in the scope of a second related pull-request.

Originally posted by @sjlongland in #72 (comment)

[sjlongland]

I managed to achieve option (3) tonight… somewhat kludgily…

https://gist.github.com/sjlongland/27d3c10a30b34a98c39c9d0545bc83ee might be worth looking at for others if like me they are using aiohttp as their web server and need to proxy amqtt. A similar technique might work for other servers like Tornado.

A native approach that avoids the need to bind an additional port would be vastly superior, but as mentioned, let's nut out a game-plan first before we start hacking code. :-)