Как рабочий ZeroMQ должен безопасно «повесить трубку»?

Я начал использовать ZeroMQ на этой неделе, и когда Используя шаблон «запрос-ответ», я не знаю, как заставить работника безопасно «повесить трубку» и закрыть свой сокет, при этом, возможно, не отбросить сообщение и не заставить клиента, отправившего это сообщение, никогда не получить ответа. Представьте себе работника, написанного на Python, который выглядит примерно так:

import zmq
c = zmq.Context()
s = c.socket(zmq.REP)
s.connect('tcp://127.0.0.1:9999')
while i in range(8):
    s.recv()
    s.send('reply')
s.close()

Я проводил эксперименты и обнаружил, что клиент по адресу 127.0.0.1:9999 имеет тип сокета zmq. REQ , который делает запрос с справедливой очередью, может иметь несчастье, потому что алгоритм справедливой организации очереди выбирает указанного выше рабочего сразу после того, как рабочий выполнил свою последнюю send () , но до того, как он выполнит следующее close () метод. В этом случае кажется, что запрос получен и буферизирован стеком ØMQ в рабочем процессе, и что запрос затем теряется, когда close () выбрасывает все, что связано с сокетом.

Как может рабочий отсоединиться «безопасно» - есть ли способ сигнализировать «Мне больше не нужны сообщения», а затем (а) перебирать все окончательные сообщения, полученные во время передачи сигнала, (б) генерировать их ответы, а затем (c) выполнить close () с гарантией, что никакие сообщения не будут выброшены?

Изменить: Я полагаю, что исходное состояние, в которое я хотел бы войти, - это «полузакрытое» состояние, в котором дальнейшие запросы не могут быть получены - и отправитель будет это знать, - но где обратный путь все еще открыт, так что я могу проверить мой входящий буфер на наличие одного последнего поступившего сообщения и ответить на него, если оно есть в буфере.

Изменить: В ответ на хороший вопрос исправлено описание, чтобы сделать количество ожидающих сообщений множественным, как может быть много соединений, ожидающих ответа.