В zmq нет ничего, что явно обнаруживало бы неожиданное завершение программы на другом конце сокета или непредвиденный и неожиданный сбой сетевого соединения.
Был исторический разговор о добавлении в zmq своего рода внутреннего пинг-понга "ты еще жив", но в прошлый раз, когда я смотрел (довольно давно), было решено не делать этого.
Это означает, что сбои, сбои в сети и т. Д. Не обязательно обрабатываются очень аккуратно, и ваше приложение не обязательно будет знать, что происходит или были ли сообщения успешно отправлены. Это актерская модель в конце концов. Когда вы обнаружите, что ваша программа может в конечном итоге определить, что-то ранее пошло не так. Тайм-ауты в zmtp определят сбой, и в конечном итоге последствия вернутся обратно в вашу программу.
Чтобы сделать что-то лучше, вам нужно наложить что-то вроде пинг-понга сверху (например, для этого есть отдельный сокет, чтобы вы могли отслеживать доступность клиентов), но затем это очень усложняет задачу. используйте приятные части ZMQ, такие как push / pull. Возможно, именно поэтому (превосходные) авторы zmq решили не вкладывать это в себя.
Когда я столкнулся с подобной проблемой, я написал свою собственную транспортную библиотеку. Я не смог найти один из готовых, который дал бы хорошее поведение перед лицом сетевых сбоев, сбоев и т. Д. Он реализовал CSP, а не модель актера, не был ужасно быстрым (неизбежность), не делал шаблонов в zmq смысл, но означал, что программы знали точно, где сообщения были всегда, и знали, что клиенты были живы или недоступны в любое время. CSPness также означал, что передача сообщений была рандомизацией при выполнении, поэтому программы знают, что делают друг друга тоже.