В семантике RPC, где Erlang надеется на лучшее, SUN RPC с по крайней мере один раз и Java RMI с максимально-раз, но никто не имеет ровно один раз семантики.
Почему кажется невозможным иметь ровно один раз семантику?
Например, если клиент продолжает пересылать запрос с уникальным тегом до получения ответа, а сервер отслеживает все обработанные запросы, чтобы не дублировать запрос. Разве это не будет ровно один раз?
Посмотрите, что произойдет, если сервер завершит сбой между выполнением запроса и записью, выполнив запрос?
Вы можете получить максимум-один раз, записав запрос, а затем выполнив его. если вы столкнетесь с крахом между ними, вы (ошибочно) записали его как выполненный, так что вы больше не будете этого делать. Следовательно, максимально-один раз
Необычно, этот (с таймаутами) запатентован: http://www.freepatentsonline.com/7162512.html. Кроме того, как я утверждаю выше, это не гарантирует ровно один раз.
Вы получаете как минимум один раз, выполняя его, а затем записывая его. Если вы столкнетесь с крахом между ними, вы повторите его, если запрос будет повторен.
Но не совсем возможно сказать "ровно один раз" во всех обстоятельствах.
(Существуют аналогичные сценарии для сетевых ошибок, а не сбоев сервера)
Высокопроизводительные шины обмена сообщениями, такие как IBM WebSphere MQ, предлагают предлагать ровно один раз с доставкой. Фактически, это поведение по умолчанию (по состоянию на последний раз, когда я использовал WMQ...). Они достигают этого с помощью журналов с записью вперед и различных методов блокировки.
Конечно, я не сомневаюсь, что где-то где-то в их юридических документах, "точно один раз" на самом деле определяется как "сообщение может или не может быть доставлено один раз, более одного раза, или много или меньше нуля". чтобы покрыть их спины, но он работает в подавляющем большинстве случаев, включая отключение силовых кабелей, передачу осей в сетевую инфраструктуру и т.д.
Я думаю, что ответ заключается в том, что для получения семантики вам потребуется неограниченное количество времени, потому что клиенту придется ждать окончательного результата с сервера, который, возможно, никогда не наступит. Это требование нецелесообразно для реальных сетей.
Если клиент когда-либо отказывается от попытки (или если сервер опускается на длительный период либо до завершения транзакции, либо перед тем, как сигнализировать о его завершении, в зависимости от того, в каком порядке он выполняет эти действия), тогда не может быть никакого способа чтобы узнать, был ли запрос получен и обработан. На практике RPC-системы могут, например, хотеть соблюдать тайм-ауты TCP по умолчанию, поэтому не хотят ждать окончательного успеха или сбоя сервера.
Это предположение: я никогда не разрабатывал протокол RPC.