Противоречие в Lamport Paxos сделало простую бумагу

Ответ 1

Вы пропустили что-то на шаге 7. Когда C обрабатывает accept 100:b, он устанавливает свое состояние в C(100:b,100). Принимая значение, node также обещает не принимать более ранние значения.

Обновление. Я думал об этом весь месяц, потому что знал, что этот ответ был не совсем правильным.

Что еще я просмотрел несколько проприетарных и open-source версий paxos, и у них у всех была ошибка, представленная OP!

Итак, правильный ответ , если смотреть полностью из Paxos Made Simple:

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

Другими словами, предлагающий может отправлять сообщения Accept акцепторам, которые он получил Promises от для этого номера бюллетеня.

Итак, это противоречие в бумаге Лампорта? Прямо сейчас, я говорю "да".

Если вы посмотрите на доказательства Lamport paxos, он рассматривает Accept как promise, как и мой первоначальный ответ. Но это не указано в Paxos Made Simple. На самом деле, похоже, Lamport приложил большие усилия, чтобы указать, что Accept не был promise.

Проблема заключается в том, что вы объединяете более слабые части обоих вариантов; как это сделал ОП, и несколько реализаций. Затем вы сталкиваетесь с этой катастрофической ошибкой.

Ответ 2

Конечно, нет проблем с передачей запроса на прием всем акцепторам. Вам не нужно ограничивать его только теми, кто ответил на исходный запрос на подготовку. Вы нашли редкий случай плохой формулировки в письме д-ра Лампорта.

В вашем контрпримеру есть ошибка. Во-первых, обозначение определяется следующим образом:

X(n:v,m), чтобы обозначить статус акцептора X: предложение n:v является самым большим нумерованным предложением, принятым X

Но тогда на шаге 7 node C имеет состояние C(100:b,-), а затем на шаге 9 оно изменилось на состояние C(1:a,-). Это не допустимый переход: после принятия 1:a он должен оставаться в состоянии C(100:b,-), так как 100:b по-прежнему является самым большим нумерованным предложением, принятым C.

Обратите внимание, что он отлично соблюдает 1:a после 100:b, по сути, потому что сеть асинхронна, поэтому все сообщения могут быть отложены или переупорядочены без нарушения чего-либо, поэтому остальная часть мира не может определить, какое предложение было в любом случае, принято первым.

Ответ 3

NECROBUMP. Даже с более слабой частью обоих вариантов нет несогласованности. Посмотрите на шаг 9 в примере в вопросе:

"Состояние: A (-: -, 100) B (100: b, 100) C (1: a, -). Выбранное предложение отменено, Paxos терпит неудачу

Однако в этот момент все, что у нас есть, является неопределенным значением, поскольку нет принятого значения большинства (мы должны в конечном итоге выбрать "b" , поскольку b был принят большинством на этапе 6.)

Чтобы продолжить протокол, нам нужны новые бюллетени, и в конечном итоге будет принят более новый бюллетень. Этот бюллетень должен иметь значение "b" ,

Доказательство: C будет отвечать (100, "b" ) на любые запросы на подготовку, поскольку принятый бюллетень с наивысшим номером (100, "b" ), даже если он в последний раз принял бюллетень (1, 'a'), B также ответит (100, 'b'). Следовательно, невозможно получить бюллетень для голосования с любым значением, но "b" .

Язык Lamport заключается в том, что акцептор ответит "Предложение с наивысшим числом меньше, чем n, которое оно приняло, если есть"

Принятый ответ смущает "наивысший номер" с "последним принятым", так как пример показывает, что акцептор может принимать значения в порядке уменьшения нумерации. Чтобы полностью совместить с протоколом Lamport, C необходимо помнить, что он ответил на (100, "b" ), даже если "последний" принимает его (1, 'a').

(Говоря, я не удивлюсь, если многие реализации не сделают это правильно и, следовательно, уязвимы для этой проблемы.)

Ответ 4

лямбда,

Ваша логика звучит, но только потому, что есть недостаток в вашем описании алгоритма Paxos. Это следует ожидать, хотя Paxos был математически доказан правильно, и проблема, которую вы указали, является одним из классических случаев конкуренции. Одна из моих критических замечаний с классической литературой Паксоса заключается в том, что эти статьи не делают, на мой взгляд, достаточно большой аргумент в пользу того, что требование фундаментальной корректности алгоритма состоит в том, что номера предложений не могут быть повторно использованы разными сверстники. Каждый раз, когда делается предложение, он должен быть уникальным, или гарантии правильности алгоритма выбрасываются прямо из окна. Если повторное использование разрешено, будет указан точный случай, который вы указали. Если вы прочтете очень внимательно, вы увидите, что это упоминается в классических документах, но не подчеркивается ни в какой степени, насколько это необходимо. Подчеркнутый, подчеркнутый и в раздражающем-мигающем тексте должен был использоваться.

Чтобы проиллюстрировать эту точку, измените ваше определение идентификатора предложения (ака круглого числа) в вашем примере как апорт ( "poposal number", "authorer unique-id" ) вместо целого числа, где упорядочение определяется как a>b if a.proposal_number > b.proposal_number or a.proposer_unique_id > b.proposer_unique_id. Вы увидите, что проблема, которую вы описываете, исчезает и что алгоритм полностью прав. В вашем примере точный сценарий описывает раздел "Неприемлемый" "Понимание Paxos" . Раздел, я мог бы добавить, что я включил чисто, потому что я оказался очень смущенным по тому сценарию, который вы указываете. Это слишком легко пропустить требование уникальности предложения id в классической литературе.

Ракис

Ответ 5

C не может принять предложение, поскольку оно не прошло через Фазу 1. IOWs для того, чтобы долина принималась акцептором, акцептор должен пройти через обе фазы протокола.

Ответ 6

если, приняв значение, node также обещает не принимать более ранние значения, алгоритм верен, но в документе Лампорт не упомянул об этом требовании, верно?

Вышеуказанное условие не требуется. Пусть говорят, что самый высокий бал, который обещал акцептор, - это X. Пусть говорят, что входящее сообщение приема имеет номер Y для голосования. Если Y < X, мы знаем, что Y должен быть отклонен. Если Y > X, это означает, что акцептор не получил запрос на подготовку для Y. Это означает, что мы получили недопустимое сообщение paxos. В этом случае сообщение accept для Y следует отбросить.

Единственное исключение - Y = 0. В этом случае выдача подготовки с номером бюллетеня 0 не имеет смысла, поскольку номера бюллетеней ниже 0 являются недопустимыми. Таким образом, фазу 1 можно пропустить для голосования 0, и предлагающий может непосредственно перейти к Фазе 2. В этом случае, то есть когда Y == 0, акцептор может принять значение, только если оно не приняло значение. Это то же самое, что вы предлагаете выше, но оно требуется только в оптимизированной версии Paxos, где фаза 1 может быть пропущена для Y == 0.

IOWs - единственный раз, когда акцептор принимает значение, когда Y == X. Единственным исключением является Y == 0. В этом случае акцептор может принять значение, только если оно не приняло значение.

Ответ 7

Я согласен с большей частью ответа Бена Брауна.

Хорошо, чтобы C принимал (1, a), он не меняет выбранное значение. Пусть говорят C принятые (1, a), и мы смотрим на историю принятия с точки зрения ученика.

(100, b), принятые B и C
(1, a) принимается C

(100, b) выбирается, поскольку он принимается большинством акцепторов.

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

Но акцепторы должны сохранить принятое предложение с наивысшим числом, если будет выпущено новое предложение.