Hacker News new | past | comments | ask | show | jobs | submit login

The ZeroMQ guide has a number of sections on discovery: http://zguide.zeromq.org/page:all#Discovery However, you could also use something like zookeeper.

The guide is a fascinating read. Even if you never write anything using ZeroMQ, it's a very useful intro to designing concurrent message passing systems.




What I got from reading that is the author has no idea how to solve the problem of many frontends and many backends of many services on a large scale (same feeling I got from reading the section about heartbeating.)


Interesting. Can you enlighten us with more detail?


The author lays out a dozen different, terrible ways to discover services, only one of which is even remotely suitable. I associate that kind of stream-of-consciousness documentation with people who are making it up as they go along.

Anyway, the proposed solution of a full-mesh FE-to-BE heartbeat network over UDP, switching to TCP in case of idleness, is not going to scale. That just guarantees that you are going to run out of file descriptors in case of a packet loss event, as everyone upgrades their heartbeat protocol to TCP.


What, in your opinion, is the correct way to implement heartbeats in such a message oriented system?




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

Search: