3 ms·

This resonated with me because I've been building services with zeromq lately. The zeromq bind and connect calls isolate the caller from managing disconnects. Z

• dpe82 13y ago
  It's a good idea until the local send buffer fills up and starts silently dropping data. There's no free lunch.
  • tlrobinson 13y ago
    In theory don't programs already need to handle that case for slow/congested connections?
    • dpe82 13y ago
      Of course, but zeromq makes it feel like you don't. It provides a message massing system that you pass messages into on one end and they magically pop out the other. If the network is slow, congested or down it'll cache messages locally until it can reconnect and send them. The problem is you don't know what's going on and if the local cache fills up it'll silently drop messages. In some use cases that's perfectly fine- it depends on your application. Zeromq is great for some things - it's super flexible and FAST. It's just not, on its own, durable. If you need durability you have to build it on top. Doable, just not free.
      • 300bps 13y ago
        You're absolutely right. It just masks the timeout from the client for as long as it can and then fails just as ungracefully.