
- •Глава 2 Связь
- •2.1. Уровни протоколов
- •2.1. Уровни протоколов 83
- •84 Глава 2. Связь
- •2.1. Уровни протоколов 85
- •2.1.1. Низкоуровневые протоколы
- •86 Глава 2. Связь
- •2.1. Уровни протоколов 87
- •2.1.2. Транспортные протоколы (метод_Метелап лр_1)
- •88 Глава 2. Связь
- •2.1. Уровни протоколов 89
- •92 Глава 2. Связь
- •2.1.3. Протоколы верхнего уровня
- •2.1. Уровни протоколов 91
- •92 Глава 2. Связь
- •2.2. Удаленный вызов процедур 93
- •2.2. Удаленный вызов процедур
- •94 Глава 2. Связь
- •2.2.1. Базовые операции rpc
- •2.2. Удаленный вызов процедур 95
- •96 Глава 2. Связь
- •2.2. Удаленный вызов процедур 97
- •98 Глава 2. Связь
- •2.2.2. Передача параметров
- •2.2. Удаленный вызов процедур 99
- •100 Глава 2. Связь
- •2.2. Удаленный вызов процедур 101
- •102 Глава 2. Связь
- •2.2. Удаленный вызов процедур 103
- •2 .2.3. Расширенные модели rpc
- •104 Глава 2. Связь
- •2.2. Удаленный вызов процедур 105
- •106 Глава 2. Связь
- •2.2.4. Пример — dce rpc
- •2.2. Удаленный вызов процедур 107
- •108 Глава 2. Связь
- •2.2. Удаленный вызов процедур 109
- •110 Глава 2. Связь
- •2.3. Обращение к удаленным объектам 111
- •2.3. Обращение к удаленным объектам
- •112 Глава 2. Связь
- •2.3.1. Распределенные объекты
- •2.3. Обращение к удаленным объектам 113
- •114 Глава 2. Связь
- •2.3.2. Привязка клиента к объекту
- •2.3. Обращение к удаленным объектам 115
- •116 Глава 2. Связь
- •2.3. Обращение к удаленным объектам 117
- •2.3.3. Статическое и динамическое удаленное обращение к методам
- •118 Глава 2. Связь
- •2.3.4. Передача параметров
- •2.3. Обращение к удаленным объектам 119
- •120 Глава 2. Связь
- •2.3.5. Пример 1 — удаленные объекты dce
- •2.3. Обращение к удаленным объектам 121
- •122 Глава 2. Связь
- •2.3.6. Пример 2 — Java rmi
- •2.3. Обращение к удаленным объектам 123
- •124 Глава 2. Связь
- •2.3. Обращение к удаленным объектам 125
- •126 Глава 2. Связь
- •2.4. Связь посредством сообщений
- •2.4.1. Сохранность и синхронность во взаимодействиях
- •2 .4. Связь посредством сообщений 127
- •128 Глава 2. Связь
- •2.4. Связь посредством сообщений 129
- •130 Глава 2. Связь
- •2.4. Связь посредством сообщений 131
- •2.4.2. Нерезидентная связь на основе сообщений
- •132 Глава 2. Связь
- •2.4. Связь посредством сообщений 133
- •134 Глава 2. Связь
- •2.4. Связь посредством сообщений 135
- •136 Глава 2. Связь
- •2.4.3. Сохранная связь на основе сообщений
- •2.4. Связь посредством сообщений 137
- •1 38 Глава 2. Связь
- •2.4. Связь посредством сообщений 139
- •140 Глава 2. Связь
2.1.2. Транспортные протоколы (метод_Метелап лр_1)
;нспортный уровень — это последняя часть того, что называют базовым стеком
евых протоколов, поскольку в нем реализованы все службы, которые необхо-
димы для построения сетевых приложений и которые не вошли в интерфейс се-
88 Глава 2. Связь
т евого уровня. Другими словами, транспортный уровень дает возможность разработчикам приложений использовать базовую сеть, лежащую в его основе.
Функции транспортного уровня
На пути от отправителя к получателю пакеты могут теряться. В то время как одни приложения задействуют собственные процедуры исправления ошибок, другие предпочитают падежную связь. Предоставить им эту службу — дело транспортного уровня. Идея состоит в том, что приложение должно быть в состоянии передать сообщение транспортному уровню и ожидать того, что оно будет доставлено без потерь.
После получения сообщения с прикладного уровня транспортный уровень разбивает его для успешной передачи на достаточно мелкие части, присваивает им последовательные номера и пересылает их. Взаимодействие на уровне заголовка транспортного уровня сводится к обсуждению того, какой пакет был послан, какой — принят, сколько места есть у адресата для приема дальнейших сообщений, что следует послать повторно и тому подобным вопросам.
Надежное транспортное соединение (которое по определению представляет собой связь с установкой соединения) можно построить поверх сетевых служб как с соединениями, так и без соединений. В первом случае все пакеты будут доставлены в правильной последовательности (если они посылаются одновременно), а в последнем возможно, что один из пакетов пойдет по другому маршруту и придет раньше, чем пакет, посланный до него. Это побуждает программное обеспечение транспортного уровня складывать пакеты в правильной последовательности, чтобы поддержать представление о транспортном соединении как о большой трубе — вы кладете в него сообщения на одном конце, и они добираются до другого неповрежденными, в том же порядке, в котором и отправлялись.
Транспортный протокол для Интернета называется протоколом управления передачей (Transmission Control Protocol, TCP). Он детально разобран в книге [109]. Комбинация TCP/IP в настоящее время является стандартом де-факто при сетевых взаимодействиях. Комплект протоколов Интернета также включает в себя не требующий соединения транспортный протокол под названием UDP (Universal Datagram Protocol — универсальный протокол датагралш), который, по сути, представляет собой IP с некоторыми небольшими дополнениями. Пользовательские программы, не нуждающиеся в протоколе с соединениями, обычно используют UDP.
Официальный транспортный протокол ISO имеет пять разновидностей — от ТР0 до ТР4. Различия относятся к обработке ошибок и к возможности работать с несколькими транспортными соединениями на базе одного соединения низкого уровня (особенно Х.25). Выбор того, какой из них использовать, зависит от свойств лежащего ниже сетевого уровня. Никогда ни один из них не должен перегружаться.
Время от времени предлагаются дополнительные транспортные протоколы. Так, например, для поддержки передачи данных в реальном времени был определен транспортный протокол реального времени (Real-time Transport Protocol, RTP). RTP — это кадровый протокол, который определяет формат пакета для