| This is super interesting, I have a very similar project that we use at Discourse https://github.com/SamSaffron/message_bus clearly being an NGINX module nchan is going to be a LOT faster That said there are few little pointers that would make integrating MessageBus with nchan a bit challenging - We have a concept of "reliable pub sub" https://github.com/SamSaffron/message_bus/blob/master/lib/me... this means that if you shut your laptop and then open it stuff just magically catches up with no loss of messages or ordering. Does the redis store you have do something similar (I can not see backing lists in the redis store implementation in store.c) - We implement per-message security, meaning you can publish to a channel/group or channel/user and only those users get the message, I see you can do auth upfront but can per-message security seems not doable. - We don't bother with per-channel URLS and instead just have a single endpoint you multi-subscribe using POST params, we often subscribe to 10 channels on a request, the multiplexing seems a bit limited - When we subscribe to a channel due to the "reliable" nature of the store we are able to tell the server what the last id is we subscribed to and catch up from there I definitely see us moving the moving our message bus server piece closer to the web server like nchan has, its by far the most scalable way, but its tough keeping feature parity. |
> We have a concept of "reliable pub sub" [...] Does the redis store you have do something similar (I can not see backing lists in the redis store implementation in store.c)
Dig a little deeper... https://github.com/slact/nchan/blob/master/src/store/redis/s... I used lua scripts for all the fancy redis logic, that's where you'll find the backing list accesses. Messages are stored as hashes, referenced by id in lists, along with some other channel metadata. So a longpoll or EventSource client knows its last message id, and can request the next avaliable message as long as said message has not yet expired. Websocket clients don't have this information, and I'm not yet sure how to relay it with each message while remaining content-agnostic. Basically, regardless of the protocol, you can send a If-Modified-Since + If-None-Match or Last-Event-ID headers and it will resume from that position in the message queue for the given channel.
> I see you can do auth upfront but can per-message security seems not doable
Per-message access will definitely not be implemented. You could, however, do this client-side by, say, encrypting the messages and sharing keys with authorized subscribers. That's kind of roundabout though.
> We don't bother with per-channel URLS [...], we often subscribe to 10 channels on a request, the multiplexing seems a bit limited
The main use-case I had in mind for multiplexing is that of a single channel per user, and some shared broadcast channel. It's currently limited to 4 max because I wanted to get this code out the door. Unlimited multiplexing will be supported in the future, and you could trivially rebuild the module to support up to 16 right now (At the cost of some memory per message per subscriber per channel overhead).
> When we subscribe to a channel due to the "reliable" nature of the store we are able to tell the server what the last id is we subscribed to and catch up from there
Yep, Nchan does that too. (except for Websocket, and hopefully I'll find a workaround)
How does that work for feature parity?