3 ms·

Hmm, interesting, and 0mq is a bit heavy. Unfortunately I can't shut down the connection, as the server needs to provide real-time updates to the clients (its p

Hmm, interesting, and 0mq is a bit heavy. Unfortunately I can't shut down the connection, as the server needs to provide real-time updates to the clients (its pub/sub), but I'll look into STCP, thanks.

kragen 7y ago
There are a couple of ghetto ways to do pubsub. Webhooks is one, and it's often by far the easiest to implement, but in other cases it's impossible. "Long polling" is another: you open a connection and tell the server what you think the current state of a variable is, and the server just sits there with the connection open until that isn't the current state of the variable any more, at which point it sends you the new current state, or the delta from the state you had to the current state, and closes the connection. If you were wrong about the current state, this happens immediately. Again, though, there are pubsub cases where this works, and pubsub cases where the extra latency and kernel CPU of opening a new TCP connection for every message are intolerable. So, to take the canonical concrete example, a chat channel might number the messages on it in a monotonically increasing order, and you might tell the server the channel name and the number of the last message you saw, at which point it sends you the messages since that point, if any, then closes the connection. As I understand it, this is how Kafka works, except for the connection-closing part. In all probability, your life will be easier and your performance will be better with ØMQ, but these hacks are things that work reasonably well and are extremely easy to implement with off-the-shelf tech. SCTP in many cases suffers from the fact that it doesn't run on top of TCP, so NATs don't know what to do with it. If you have enough control over your network that that isn't a concern for you, UDP with IP multicast is another plausible solution, the one TIBCO used originally IIRC; you can allocate a multicast IP address per pubsub channel or multiplex them. With IP multicast, recovery from lost messages is a concern, especially if 802.11 is part of your network (since 802.11 uses hop-by-hop ACKs for unicast packets) but there are a variety of reliable multicast protocols like SRM to handle that. Feel free to hit me up for more info, I've been hacking around with different ways of doing pubsub since the previous millennium.
- StavrosK 7y ago
  That's very informative, thank you for taking the time. Just so you have more context, this is what I'm using this in: https://gitlab.com/stavros/itsalive https://gitlab.com/stavros/itsalive Clients can connect to the server and get updates for the commands that are currently running, which is not high throughput or complex from a networking perspective. I was wondering if there was something lightweight that will do the same, and 0mq seems like the best choice, but a simple loop over the connections seems to work well as well. I played around with 0mq for this and it works great, but in this instance I might not want to add the extra dependency (especially since I've already implemented it, minus a bug where it'll block if a packet is exactly 4k). I think adding an "end of message" character (eg a newline) would be the simplest thing to do in this instance.
  - kragen 7y ago
    Yeah, that sounds like the best choice. (That's the SLIP framing approach.) SCTP probably isn't viable if you want random people to be able to watch the presentation without rebuilding their kernels, and multicast IP isn't viable on the global internet. An IRC server would work fine, and you might even be able to just use a secret channel on Freenode, but some places block IRC because of other pubsub software that uses it.
    - StavrosK 7y ago
      Yeah, I wouldn't want to burden Freenode with that, but IRC is an interesting choice. I'll use the terminating character, thanks for your time!
      - kragen 7y ago
        Right, the benefit of using IRC is that you don't have to write the server; there are dozens of well-known, actively-maintained free-software servers, they're well-documented, and they already support epoll and kqueue and have reasonable ways of handling all kinds of pathological network conditions. But maybe a simple asyncio-based event loop, or even threads, would be fine for itsalive.

kragen 7y ago

There are a couple of ghetto ways to do pubsub. Webhooks is one, and it's often by far the easiest to implement, but in other cases it's impossible. "Long polling" is another: you open a connection and tell the server what you think the current state of a variable is, and the server just sits there with the connection open until that isn't the current state of the variable any more, at which point it sends you the new current state, or the delta from the state you had to the current state, and closes the connection. If you were wrong about the current state, this happens immediately. Again, though, there are pubsub cases where this works, and pubsub cases where the extra latency and kernel CPU of opening a new TCP connection for every message are intolerable. So, to take the canonical concrete example, a chat channel might number the messages on it in a monotonically increasing order, and you might tell the server the channel name and the number of the last message you saw, at which point it sends you the messages since that point, if any, then closes the connection. As I understand it, this is how Kafka works, except for the connection-closing part. In all probability, your life will be easier and your performance will be better with ØMQ, but these hacks are things that work reasonably well and are extremely easy to implement with off-the-shelf tech. SCTP in many cases suffers from the fact that it doesn't run on top of TCP, so NATs don't know what to do with it. If you have enough control over your network that that isn't a concern for you, UDP with IP multicast is another plausible solution, the one TIBCO used originally IIRC; you can allocate a multicast IP address per pubsub channel or multiplex them. With IP multicast, recovery from lost messages is a concern, especially if 802.11 is part of your network (since 802.11 uses hop-by-hop ACKs for unicast packets) but there are a variety of reliable multicast protocols like SRM to handle that. Feel free to hit me up for more info, I've been hacking around with different ways of doing pubsub since the previous millennium.

StavrosK 7y ago
That's very informative, thank you for taking the time. Just so you have more context, this is what I'm using this in: https://gitlab.com/stavros/itsalive https://gitlab.com/stavros/itsalive Clients can connect to the server and get updates for the commands that are currently running, which is not high throughput or complex from a networking perspective. I was wondering if there was something lightweight that will do the same, and 0mq seems like the best choice, but a simple loop over the connections seems to work well as well. I played around with 0mq for this and it works great, but in this instance I might not want to add the extra dependency (especially since I've already implemented it, minus a bug where it'll block if a packet is exactly 4k). I think adding an "end of message" character (eg a newline) would be the simplest thing to do in this instance.
- kragen 7y ago
  Yeah, that sounds like the best choice. (That's the SLIP framing approach.) SCTP probably isn't viable if you want random people to be able to watch the presentation without rebuilding their kernels, and multicast IP isn't viable on the global internet. An IRC server would work fine, and you might even be able to just use a secret channel on Freenode, but some places block IRC because of other pubsub software that uses it.
  - StavrosK 7y ago
    Yeah, I wouldn't want to burden Freenode with that, but IRC is an interesting choice. I'll use the terminating character, thanks for your time!
    - kragen 7y ago
      Right, the benefit of using IRC is that you don't have to write the server; there are dozens of well-known, actively-maintained free-software servers, they're well-documented, and they already support epoll and kqueue and have reasonable ways of handling all kinds of pathological network conditions. But maybe a simple asyncio-based event loop, or even threads, would be fine for itsalive.