[throwaway9870]

The problem is that it started out as any but stable and reliable. It asserted on received data, which in a network application is a super newbie mistake. When I looked at it, the pub/sub socket would hang forever if the other end interrupted the connection. So the zeromq guide which said "look how easy it is" was only true if you ignored errors. If you are writing network code and ignore errors, well, good luck. That was a long time ago (~10yrs) so if it is better now, good for them. Also, both founders have left the project. One passed from cancer, the other didn't like what he built and started over in C. Not that they can't be replaced, but transitions can be hard and take time.

[chomp]

> When I looked at it, the pub/sub socket would hang forever if the other end interrupted the connection.

You just gave me openstack+zeromq flashbacks

[jvanderbot]

Yes - nanomsg / nng are quite good. I think / believe they'll be part and parcel for some space missions soon enough.

[victor106]

> It asserted on received data, which in a network application is a super newbie mistake

What do mature network applications do instead?

[throwaway9870]

What I mean is literally have an assert with incoming data as the parameter:

> assert(data_buf[4] < 8);

While your protocol might guarantee that data_buf[4] should always be a value less than 8, you don't use assert() to check it because it aborts the program if the check fails. The proper thing to do is a range check that returns an error for a protocol error (malformed data, etc.).

ZeroMQ literally called assert and any bad data coming in over the wire would cause your app to abort. Insane.

Here is an example bug report:

https://github.com/zeromq/libzmq/issues/186

Keep in mind this was a LONG time ago! So this is not an indictment of the current project!

[praptak]

TCP asserts on received data, so I guess GP really meant reliable message queues. They generally assert after commit to disk.