Руководящие принципы разработки протокола

Question

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

Layer1             
---------------             
| ^^           
| (1) |(4) |(6) 
v  | |           Remote entity 
----------------          --------------- 

    Layer0-----------------(2)------------------------------->Layer0 
    Layer0<----------------(3)--------------------------------Layer0 
    Layer0<----------------(5)--------------------------------Layer0 


1. New session request to remote entity. 
2. Establish link + data(session request) 
3. Link Establishment ongoing 
4. Link Establishment pending 
5. Link Established + data (session accepted) 
6. session accepted. 

Если layer1 решает, что он не нужен дистанционный Entities обслуживание между шагом 4 и 6. т.е. событие 4 получено и события 6 еще не получил из-за какой-то ошибки.

1) Должна ли она ждать события 6 произойдет, и инициировать выпуск сеанса или
2) Layer1 следует проинструктировать Layer 0, чтобы завершить процедуру установления соединения
немедленно.

Каков правильный путь?

Проблема с (1) будет, даже если мы знаем, что мы собираемся завершить сеанс из-за ошибки, нам нужно обрабатывать другие события, прежде чем event6 приходит.

Answer 1

Я фанат fail fast конструкций. Как только вы узнаете, что вы не можете продолжить, вы должны уведомить другую сторону и выйти.

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

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

Мне также не нравятся сторожевые таймеры, основанные на времени (поскольку время, которое разработчик выбирает, никогда не бывает правильным для всех ситуаций), но для таких протоколов вам часто приходится определять худший сценарий, когда другая сторона никогда не отвечает на ваше сообщение fail. В этих ситуациях настраиваемый тайм-аут обычно является единственным способом очистки. Тайм-ауты всегда должны быть последним средством, а не первым.

Answer 2

Есть 4 сообщения в строке в одном направлении (через слои) без подтверждения с принимающей стороны? Создание клиента для отправки подтверждающих сообщений, таких как пакеты SYN-ACK/RST в TCP, автоматически позаботится о рассматриваемом сценарии, а также поможет в других режимах ошибок (когда клиент или сеть не работают).

Answer 3

В вашем протоколе и соответствующих таймаутах должно быть добавлено некое (не) сообщение подтверждения. Затем запрос уровня 1, чтобы отменить ожидающий сеанс, может быть реализован посредством nack к следующему сообщению с вашего удаленного сеанса или просто к отказу вашего клиента вообще ответить на ответ удаленного сеанса и время удаленного сеанса из-за бездействия.

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

Answer 4

1) Должна ли она ждать события 6 произойдет и инициировать релиз сессии

ИМХО, вы никогда не должны блокировать клиента по запросу терминации. Возможно, приложение закрывается, потому что система отключается. В любом случае вы не можете этого сделать, администратор имеет управление выключателем питания на самом низком уровне. Непринятие этой реальности заработает на вашем протоколе репутацию репутации раздражающего.

2) Layer1 следует проинструктировать Layer 0 прекратить выполнение процедуры установления соединения

Да.

Я заметил, что слой 1 может также потребоваться отменить в любое время после шага 1, а не только после шага 4.

Похоже любое время после шага 2, это может занять какой-то степени «раскручивание» прекратить ,

У локальных и удаленных объектов есть сетевая задержка между ними и может иметь разные представления о состоянии вещей в любой момент времени. Например, локально вы, возможно, выполнили шаг 2, в то время как удаленный объект полагает, что он завершен шаг 5. Если сообщения могут появляться не в порядке (например, UDP), возникают еще больше возможностей.

«Прекращение» может быть или не быть успешным в разной степени. Что произойдет, если вы отправите свой шаг 2, а затем завершение, но никогда не услышите назад от удаленного объекта?

Клиенты более высокого уровня могут предъявлять дополнительные требования. Например, отменяется после шага 5, отличного от шага 2? Выполняют ли шаги 3 и 5 постоянную модификацию удаленного объекта (например, фиксацию базы данных)? Должен ли клиент более высокого уровня знать, как далеко продвинулись вещи до того, как его запрос на завершение был обработан?

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

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

Answer 5

Можете ли вы сказать мне, какое преимущество есть в ожидании? Вы уже указали, что есть проблемы с этим подходом, и это звучит для меня, как будто вы уже обнаружили, что вариант 2 на самом деле лучший способ. Правильность - это только вопрос мнения, но, я бы сказал, вариант 2.

Слой 1 должен проинструктировать слой 0, чтобы завершить процесс соединения. Эта процедура также должна проинструктировать слой 0, что он больше не заинтересован в получении событий. Затем уровень 1 может продолжаться в отключенном состоянии.

Для меня это самая простая и самая очевидная вещь, которую нужно сделать и наименее проблематичным. Как вы уже сказали, вам не нужно обрабатывать какое-либо состояние на уровне 1, потому что вам не понадобятся эти другие сообщения, когда вы уже закрыли соединение.