| Nice project, and a curious featureset overlap, too... > 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? |
regarding that implementation, one diff I am spotting is that I also have a concept of global message id / global channel, this allows us to subscribe to a single spot and distribute from there (which keeps thread counts down and is particularly useful for server -> server comms.)
A lot of parity with our projects :)
Regarding web sockets, I decided against supporting them (initial implementations did) the issue is that web sockets are 100% flaky on HTTP and just add tons of unneeded complexity, in advent of HTTP/2 in NGINX they would be a net loss imo cause you would be wasting a connection.