Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Last time I looked into zmq, it was not recommended for use in public internet services -- not resilient enough against a potential DoS attack or buggy client implementation. Has this changed?


Through versions 2.x, there were assert()s peppered throughout the code that could be triggered if malformed data was sent over the wire, making it unsuitable for internet exposure. There was also behavior in durable sockets where messages delivered to an identity that had disappeared would accumulate in memory, effectively manifesting as a memory leak.

3.x removes the asserts so you can't segfault remotely. 3.x also transparently drops messages on the floor destined for unroutable identities. This silent dropping sounds annoying, but you can work around it via a well-designed application protocol. Remember, 0MQ is effectively a transport layer, not a full-blown messaging system.


It have got much better. The latest stable version should be pretty much resilient.


I don't think it's supposed to be exposed in this way, rather it's very good for internal wiring between trusted systems.


If I recall, the issue with a public 0mq socket was that anyone driving by sending something 0mq didn't like would cause an assertion to fail, so your process would crash. It wasn't so much a "supposed to be exposed" as "expose it and crash".


Yes you are right. I guess what I wanted to say, is that 0MQ relies on trusted code and network. It's okay for code to assert, as soon as there is someone to fix it, and it's probably expected. (Crash early, fix early).




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: