WWW.DISSERS.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА

   Добро пожаловать!


Pages:     | 1 |   ...   | 2 | 3 || 5 |

Протокол TCP, с другой стороны, является протоколом с установлением соединения, и предоставляет полный спектр услуг, но цена этого - более высокиеиздержки. Длина заголовка TCP составляет 20 байт. Также протокол порождает большоеколичество дополнительных пакетов, вызванных исключительно потребностями процедур управления, таких как установка соединения, разрыв соединения и подтверждениеприема пакета.

5.2.1. Сегментация и восстановление Транспортные протоколы с установлением соединения разработаны для передачи большого количества данных, при этом информация должна быть разбита на сегменты, умещающиеся в отдельных пакетах. Сегментация данных и нумерация сегментов являются важным элементом процесса передачи и помимо этого делают осуществимым выполнениедругих функций, таких как исправлениеошибок. Процесс маршрутизации, выполняемый на Сетевом уровне, является динамическим; и в случаепередачи данных возможно возникновениеситуации, когда сегменты следуют до места назначения разными путями и приходят не в том порядке, как они были отправлены. Нумерация сегментов позволяет принимающей системе восстановить исходный порядок следования сегментов. Эта нумерация также дает возможность системеполучателю сообщить отправителю, какой из пакетов был поврежден или потерян. В результате отправительможет не повторять целиком всю передачу, а повторно переслать только потерянные сегменты.

5.2.2. Управление потоком данных Управление потоком данных (flow control) - это одна из функций, обычно предоставляемая протоколами Транспортного уровня с установлением соединения. Она представляет собой механизм, согласно которому система, принимающая данные, может сообщить отправителю о том, что он должен снизить скорость передачи данных, или об опасности перегрузки системыполучателя и потери данных. Заголовок TCP, например, включает в себя поле Window, при помощи которого получатель устанавливает количество байт, котороеон может принять ототправителя в единицу времени. Если это значениев пакетах, успевших дойти, уменьшается, то отправительзнает, что он должен уменьшить скорость передачи. Когда значениеначинает расти снова, отправительможет увеличить скорость пересылки.

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

Другая и наиболее широко применяемая форма исправления ошибок на Транспортном уровне представляет собой законченный процесс, начинающийся с обнаружения ошибок и заканчивающийся их коррекцией. Этотпроцесс охватывает и ошибки, которые еще не были обнаружены каким-либо другим способом. Несмотря на то что большинство протоколов Канального уровня имеют свои собственные механизмы выявления и коррекции ошибок, они функционируют только при промежуточных пересылках между двумя системами. Механизм выявления ошибок Транспортного уровня обеспечивает контрольошибок на всем участке между двумя конечными системами и включает в себя возможность исправления ошибок, которая осуществляется путем запроса уотправителя повторной передачи определенных пакетов. Для осуществления этого в заголовок протокола Транспортного уровня включена контрольная сумма, значениекоторой получено из полей, не меняющихся в ходевсего путешествия до места назначения. Периодически изменяющиеся поля, такиекак индикатор Time-to-Live, значениекоторого увеличивает каждый маршрутизатор, обрабатывающий пакет, исключены из вычисления контрольной суммы.

6. Сеансовый уровень Начиная с Сеансового уровня, границы между уровнями и их функциями становятся более расплывчатыми. Нельзя выделить отдельный протокол, который функционировал бы исключительно на Сеансовом уровне. Более того, функциональные возможности Сеансового уровня поддержаны другими протоколами, в том числефункции, попадающиев сферудеятельности протоколов Представительского и Прикладного уровней. NetBIOS (Network Basic Input/Output System, сетевая базовая система ввода/вывода) и NetBEUI (NetBIOS Extended User Interface, расширенный пользовательский интерфейс NetBIOS) — показательные примеры таких протоколов.

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

Сеансовый уровень также не имеет особого значения для обеспечения безопасности и процессов регистрации в сети, как это может показаться, глядя на его название. Более того, основные функции этого уровня связаны с обменом сообщениями между двумя конечными системами. Этот обмен называется диалогом (dialog). Помимо указанной функции, Сеансовый уровень обеспечивает множество других, являясьпоистине многоцелевым “инструментарием” для разработчиков программного обеспечения.

Сервисы, обеспечиваемые Сеансовым уровнем, очень широко трактуются.

Даже во время разработки модели OSI существовал ряд вопросов относительно того, к какому уровню их отнести. Двадцать два различных сервиса, предоставляемые Сеансовым уровнем, собраны в три подгруппы: блок функций ядра (Kernel Function Unit), подмножество основных действий (Basic Activity Subset) и подмножество основной синхронизации (Basic Synchronization Subset). Большинство этих сервисов интересны только разработчикам, а некоторые даже дублируются в результате компромисса, принятого комитетами во время слияния двух стандартов при создании модели OSI.

Взаимодействиемежду уровнями модели OSI упрощается за счет применения примитивов службы запросов (service request primitives), представляю щих собой отдельные средства инструментария разработчика. Каждый уровень предоставляет услуги уровню, расположенному непосредственно над ним. Процесс использования уровнем услуг, оказываемых нижележащим уровнем, осуществляется путем выполнения команд, предлагаемых соответствующим примитивом службы запросов, с указанием значений дополнительных требуемых параметров. Таким образом, процесс Прикладного уровня осуществляет запрос сетевого ресурса, используя примитив, предложенный Представительским уровнем. Когда запрос передается вниз через уровни, каждый из них задействует соответствующий примитив нижележащего уровня. Этотпроцесс выполняется до тех пор, пока сообщениене будет готово для передачи по сети. Как только пакет достигнет своего места назначения, он преобразуется в указательные примитивы (indication primitives), которые передаются вверх через уровни стека процессу приложенияполучателя.

Управлениедиалогом и разделениедиалогов - два наиболее важных сервиса, относящихся к Сеансовому уровню. Управление диалогом (dialog control) - это средство, которое позволяет двум системам начать диалог, обменяться сообщениями, а послезакончить диалог с уверенностью, что каждая система получила предназначенные для нее сообщения. Это может показаться простой задачей, но примем во вниманиетотфакт, что система может передать сообщение другой системе и получить назад сообщение без уверенности в том, что это ответ. Было ли принятоесообщениеответной посылкой или оно было передано раньше Такой тип коллизии может вызвать серьезные проблемы, особенно когда одна из систем пытается завершить диалог или создать контрольную точку.

Разделение диалога (dialog separation) - это процесс вставки указателей в поток данных, доставляемых между двумя системами. Эти указатели называются точками контроля (checkpoints), они размещаются таким образом, что в один и тотже момент времени может быть получена информация о состоянии обеих систем.

6.1. Управление диалогом Когда две системы вступают в диалог Сеансового уровня, они выбирают один из двух режимов управления обменом сообщениями на всевремя сеанса: либо полудуплексный обмен, либо дуплексный. Каждоесеансовоесоединение имеет уникальный идентификатор размером 196 байт, состоящий из четырех элементов:

• указатель SS-USER инициатора;

• указатель SS-USER ответчика;

• общий указатель;

• дополнительный указатель.

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

При полудуплексном режиме в любой из моментов времени только одна из систем может передавать сообщения. Право передачи определяется посредством маркера данных (data token). Каждая система по завершении передачи отправляет маркер другой системе, используя примитив S-TOKEN-GIVE.

Только получив маркер, другая система может начать передачусвоего сообщения. Также существует примитив S-TOKEN-PLEASE, который система может использовать для того, чтобы запросить маркер.

Использованиедуплексного режима значительно усложняет процесс обмена.

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

Важно понимать, что маркер и соединениена Сеансовом уровне не имеют ничего общего с одноименными элементами нижележащих протоколов. Маркер Сеансового уровня не является эквивалентом маркера, используемого протоколом Token Ring, как и соединениеСеансового уровня не эквивалентно соединению Транспортного уровня протокола TCP. Две системы могут разорвать соединениеСеансового уровня, в то время как соединениеТранспортного уровня будет открыто для дальнейшего обмена.

Использованиемаркера предотвращает возникновениепроблем, связанных с перекрестными сообщениями, и обеспечивает механизм упорядоченного завершения (orderly termination) соединения между системами. Согласно порядку процедуры завершения соединения, одна из систем сигнализирует о своем намерении разорвать соединениеи передает маркер. Другая система, получив маркер, пересылает вседанные, оставшиеся в ее буферах, и использует примитив S-PLEASE, чтобы подтвердить прием запроса разъединения.

Приняв примитив S-PLEASE, первая система знает, что она получила отдругой системы вседанные, ожидавшиеотправки. Теперь она может использовать примитив S-DISCONNECT для разрыва соединения.

В управлении диалогом предусмотрен механизм согласованного разъединения (negotiated release). Он дает возможность одной системе отказать другой системе в разъединении. Эта возможность используется в случаепоявления коллизии, которая может возникнуть, если обе системы одновременно сделают запрос на разъединение Также существует маркер разъединения.

(rеlease token), который в первую очередь служитдля предотвращения возникновения подобных коллизий. Он позволяет сделать запрос на разъединениетолько одной из систем.

Все эти механизмы являются “инструментами” из набора средств, который Сеансовый уровень предоставляет разработчикам приложений; они не являются автоматически выполняющимися фоновыми процессами. Когда создается приложение разработчик должен сам принять решениео соответствии, используемых примитивов поставленной задаче. Например, употребить примитив S-TOKEN-GIVE вместо примитива S-TOKEN-PLEASE, или применить согласованноеразъединениевместо упорядоченного.

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

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

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

В дуплексном (полнодуплексном) режиме также возможно применениепростой синхронизации. Для этого используется специальный маркер простой синхронизации, который удерживает обе системы отодновременной передачи примитива S-SYNC-MINOR. Если бы было возможно переключиться из дуплексного режима в полудуплексный, не разрывая соединения, то в применении дополнительного маркера не было бы необходимости, но переключиться между режимами невозможно. Это как раз то, что многиелюди считают основным недостатком в спецификации Сеансового уровня.

В большинстве случаев системы, использующие дуплексный режим соединения, должны выполнять сложную синхронизацию (major synchronization), которая отвечает не только за трафик, который может передаваться в обоих направлениях, но также и за скоростной трафик. Примитив S-EXPEDITED позволяет осуществить передачуотодной системы к другой, используя высокоскоростной канал, отделенный отобычных коммуникационных каналов.

Выполняя рассматриваемую синхронизацию, система, владеющая маркером сложной синхронизации (major/activity token), отправляет примитив SSYNC-MAJOR, а затем останавливает передачудо тех пор, пока не получит ответ. Тем не менее, система, пославшая этотпримитив, не может пока еще создать контрольную точку, как это легко получается при простой синхронизации, поскольку трафик отдругой системы в данный момент может ещё передаваться.

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

точки контроля.

7. Представительский уровень В отличиеотСеансового уровня, который обеспечивает множество различных функций, Представительский уровень имеет только одну. На самом деле большую часть времени Представительский уровень в основном функционирует как служба перевода (pass-through service). Это значит, что он получает примитивы отПрикладного уровня и передает их дубликаты вниз Сеансовому уровню, используя точку доступа к сервису Представительского уровня (PSAP, Presentation Service Access Point) и точку доступа к сервису Сеансового уровня (SSAP, Session Service Access Point). Всерассуждения предыдущих разделов об использовании приложениями служб Сеансового уровня в действительности, хотя и неявно, уже затрагивали вопросы, связанные со службой перевода Представительского уровня, так как процессы на любом уровне модели OSI могутнепосредственно взаимодействовать только с соседними уровнями.

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

Приложение создает запрос к сетевым ресурсам, используя свой “родной” синтаксис, однако язык системы, принимающей запрос, может быть отличным. Например, соединениемежду PC и Mainframe может потребовать перекодирования сообщений из ASCII в EBCDIC. Системы могут также применять шифрованиеи/или сжатиеданных, передаваемых через сеть.

Pages:     | 1 |   ...   | 2 | 3 || 5 |






















© 2011 www.dissers.ru - «Бесплатная электронная библиотека»

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