Я изучаю zmq с привязкой PyZMQ, и у меня проблемы с шаблоном Lazy Pirate. Итак, вот код для сервера Lazy Pirate и Клиент Lazy Pirate.
В примере клиент отправляет запрос, но это просто номер. Как я могу сделать реальный запрос с текстовыми данными и сохранить реализацию шаблона?
Кроме того, я не очень понимаю переменную sequence в клиентском коде - она бесконечно увеличивается => не произойдет ли сбой python, когда sequence достигнет максимума переменной int?
Начнем с того, что переменная sequence в коде по сути является идентификатором сообщения. Есть два способа, при которых одна попытка запроса может потерпеть неудачу:
Во втором случае, если у вас нет числа sequence, вы не знаете, какой из ваших запросов на самом деле был успешным.
Рассмотрим эту историю клиента:
Какой запрос вызвал ответ? Это может быть любой из трех запросов из-за второго типа отказа запроса, упомянутого выше. С числом sequence в ответе мы можем точно знать, какой запрос обрабатывается сервером.
Идея «Искаженного ответа от сервера» в образце клиента заключается в том, что если клиент находится на запросе № 3 (с истечением времени ожидания на запросы № 1 и № 2), он отбрасывает ответы № n (где n ‹ 3) пока не дойдет до ответа №3, который он принимает.
Чтобы отправить больше, чем порядковый номер, используйте формат сериализации и отправьте объект целиком.
Например, я мог бы определить class MyRequest { int sequence; string text; }, а затем отправить это как JSON на сервер.
Бесконечно увеличивающуюся переменную sequence можно заменить на int64, и тогда все будет в порядке, или вы можете сделать что-то вроде использования GUID в качестве идентифицируемого запроса.
К сожалению, ответ Тимоти Шилдса выше на 100% неверен. Вы можете прочитать комментарии Хинтьена в этой бесплатной версии его книги Code Connected Volume 1. . Важный бит со страницы 141 выглядит следующим образом...
Клиент упорядочивает каждое сообщение и проверяет, возвращаются ли ответы точно по порядку: никакие запросы или ответы не теряются, а ответы не возвращаются более одного раза или не по порядку. Запустите тест несколько раз, пока не убедитесь, что этот механизм действительно работает. Вам не нужны порядковые номера в рабочем приложении; они просто помогают нам доверять нашему дизайну.
Интересное обсуждение того, как может выйти из строя открытый TCP, находится здесь хорошее обсуждение. Прочитайте комментарии. Я не сомневаюсь, что Тим очень хорошо осведомлен, он просто ошибся, не распознав, что ленивый пиратский шаблон, в частности, ТОЛЬКО использует REQ-REP, и поэтому он более надежен, чем предполагают его комментарии.
