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

Question

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

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

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

Answer 1

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

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

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

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

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

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

Answer 2

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

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

Answer 3

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

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

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