Эталонная сетевая модель OSI. Чернышов М.К. - 27 стр.

UptoLike

Составители: 

27
системе в разъединении. Эта возможность используется в случае появления
коллизии, которая может возникнуть, если обе системы одновременно сде -
лают запрос на разъединение. Также существует маркер разъединения
(rе lease token), который в первую очередь служит для предотвращения воз -
никновения подобных коллизий . Он позволяет сделать запрос на разъедине-
ние только одной из систем .
Все эти механизмы являются инструментами” из набора средств , который
Сеансовый уровень предоставляет разработчикам приложений ; они не явля -
ются автоматически выполняющимися фоновыми процессами. Когда созда -
ется приложение, разработчик должен сам принять решение о соответствии
используемых примитивов поставленной задаче. Например , употребить при-
митив S-TOKEN-GIVE вместо примитива S-TOKEN-PLEASE, или применить
согласованное разъединение вместо упорядоченного.
6.2. Разделение диалога
Приложения создают контрольные точки, чтобы сохранить свое текущее со-
стояние на диске на случай системного сбоя . Во время разработки модели
OSI этот метод более широко использовался , нежели сейчас. Как и в случае с
процессами управления диалогом , которые обсуждались ранее, процедура
расстановки контрольных точек должна быть явно определена разработчи-
ком , если в ней есть необходимость.
Когда приложение вовлекло во взаимодействие через сеть две системы, кон -
трольная точка должна обеспечить сохранение состояния обеих систем в
один и тот же момент. Выполнить согласованное действие на двух различ -
ных компьютерах в точно определенный момент почти невозможно. Систе-
мы могут осуществлять тысячи действий в секунду , и их синхронизация
должна быть точна настолько, насколько это необходимо для одновременно-
го выполнения конкретной задачи. Вдобавок возникает проблема сообщений ,
которые могут быть еще в пути во время создания контрольной точки. В ре-
зультате разделение диалога посредством сохранения контрольной точки в
определенном месте потока данных, пересылаемого между двумя системами,
оказывается точнее, чем выполнение этого действия в определенный момент
времени.
В полудуплексном режиме процесс создания контрольных точек сравнитель-
но прост. Одна система создает точку контроля и отправляет примитив, на-
зываемый S-SYNC-MINOR. Другая система, получив этот примитив, создает
свою собственную точку контроля , уверенная в том , что во время синхрони-
зации не осталось данных, находящихся в процессе передачи. Такой процесс
называется простой синхронизацией (minor synchronization), так как он ра-
ботает с потоком данных, следующим только в одном направлении, и требует
только одной операции обмена управляющими сообщениями.
В дуплексном (полнодуплексном ) режиме также возможно применение про-
стой синхронизации. Для этого используется специальный маркер простой
                                    27
системе в разъединении. Эта возможность используется в случае появления
коллизии, которая может возникнуть, если обе системы одновременно сде-
лают запрос на разъединение. Также существует маркер разъединения
(rеlease token), который в первую очередь служит для предотвращения воз-
никновения подобных коллизий. Он позволяет сделать запрос на разъедине-
ние только одной из систем.
Все эти механизмы являются “инструментами” из набора средств, который
Сеансовый уровень предоставляет разработчикам приложений; они не явля-
ются автоматически выполняющимися фоновыми процессами. Когда созда-
ется приложение, разработчик должен сам принять решение о соответствии
используемых примитивов поставленной задаче. Например, употребить при-
митив S-TOKEN-GIVE вместо примитива S-TOKEN-PLEASE, или применить
согласованное разъединение вместо упорядоченного.


6.2. Разделение диалога

Приложения создают контрольные точки, чтобы сохранить свое текущее со-
стояние на диске на случай системного сбоя. Во время разработки модели
OSI этот метод более широко использовался, нежели сейчас. Как и в случае с
процессами управления диалогом, которые обсуждались ранее, процедура
расстановки контрольных точек должна быть явно определена разработчи-
ком, если в ней есть необходимость.
Когда приложение вовлекло во взаимодействие через сеть две системы, кон-
трольная точка должна обеспечить сохранение состояния обеих систем в
один и тот же момент. Выполнить согласованное действие на двух различ-
ных компьютерах в точно определенный момент почти невозможно. Систе-
мы могут осуществлять тысячи действий в секунду, и их синхронизация
должна быть точна настолько, насколько это необходимо для одновременно-
го выполнения конкретной задачи. Вдобавок возникает проблема сообщений,
которые могут быть еще в пути во время создания контрольной точки. В ре-
зультате разделение диалога посредством сохранения контрольной точки в
определенном месте потока данных, пересылаемого между двумя системами,
оказывается точнее, чем выполнение этого действия в определенный момент
времени.
В полудуплексном режиме процесс создания контрольных точек сравнитель-
но прост. Одна система создает точку контроля и отправляет примитив, на-
зываемый S-SYNC-MINOR. Другая система, получив этот примитив, создает
свою собственную точку контроля, уверенная в том, что во время синхрони-
зации не осталось данных, находящихся в процессе передачи. Такой процесс
называется простой синхронизацией (minor synchronization), так как он ра-
ботает с потоком данных, следующим только в одном направлении, и требует
только одной операции обмена управляющими сообщениями.
В дуплексном (полнодуплексном) режиме также возможно применение про-
стой синхронизации. Для этого используется специальный маркер простой