Почему семантика невозможна?

Question

В семантике RPC, где у Erlang есть надежда на лучшее, SUN RPC с хотя бы один раз и Java RMI с самое большее один раз, но никто не имеет семантики точно один раз.

Почему кажется невозможным иметь ровно одну семантику?

Например, если клиент продолжает повторную отправку запроса с уникальной меткой, пока не получен ответ, а сервер отслеживает все обработанные запросы, чтобы не дублировать запрос. Разве это не будет точно один раз?

Answer 1

Подумайте, что произойдет, если произойдет сбой сервера между выполнением запроса и записью, что он выполнил запрос?

Вы можете получить самое большее один раз, записав запрос, а затем выполнив его. если между ними возникнет сбой, то вы (ошибочно) записали его как выполненное, поэтому вы не будете делать это снова. Следовательно самое большее один раз

Как ни странно, этот (с таймаутами) запатентован: http://www.freepatentsonline.com/7162512.html. За исключением того, что, как я утверждаю выше, он не гарантирует точно один раз.

Вы получаете хотя бы один раз, выполняя это, затем записывая это. Если между ними возникнет сбой, вы выполните его снова, если запрос будет повторен.

Но на самом деле невозможно сказать «ровно один раз» при любых обстоятельствах

(Существуют похожие сценарии для сетевых ошибок, а не для сбоев сервера)

Answer 2

Высококачественные шины обмена сообщениями, такие как IBM WebSphere MQ , действительно предлагают доставку только один раз. Фактически, это поведение по умолчанию (по состоянию на последний раз, когда я использовал WMQ ...). Они достигают этого с помощью журналов записи вперед и различных методов блокировки.

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

Answer 3

Я думаю, что ответ заключается в том, что вам понадобится неопределенное количество времени для получения этой семантики, потому что клиенту придется ждать окончательного результата от сервера, который может никогда не прийти. Это требование неосуществимо в реальных сетях.

Если клиент когда-либо прекращает попытки (или если сервер отключается на длительный период либо до завершения транзакции, либо до того, как сигнализирует о ее завершении, в зависимости от того, в каком порядке он выполняет эти действия), тогда может быть невозможно клиент должен знать, был ли запрос получен и обработан. На практике, системы RPC могут, например, хотеть соблюдать таймауты TCP по умолчанию, поэтому не хотят ждать окончательного успеха или отказа от сервера.

Это предположение: я никогда не проектировал протокол RPC.