Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
Подписываем
Протокол UDP определен в RFC 768. В отличие от TCP, он не ориен тирован на соединение и не обеспечивает подтверждение приема, управление потоком, сегментацию и гарантированную доставку. В результате UDP намного проще TCP и создает гораздо меньше на грузки на сеть. Это связано не только с тем, что заголовок UDP коро че заголовка TCP (8 байтов против не менее 20). В UDP нет специ альных управляющих сообщений, например, сообщений для установ ки или разрыва соединения. Транзакция UDP состоит всего из двух сообщений — запроса и ответа, причем последний служит также не явным подтверждением приема. По этим причинам, приложения, использующие UDP, могут передавать лишь небольшие порции дан ных, которые могут уместиться в единственное сообщение. В основ ном сообщения UDP применяются протоколами прикладного уров ня DNS и DHCP. В определенных ситуациях UDP можно использо вать и для передачи больших объемов данных, например, в аудио- и видеопотоках. В данном случае использование UDP допустимо, по скольку периодическая потеря пакетов важной роли не сыграет.
Функции полей сообщения UDP таковы:
• Source Port (2 байта) — идентификатор процесса в передающей системе, который сгенерировал информацию в поле данных.
• Destination Port (2 байта) — идентификатор процесса в принимаю щей системе, которому предназначается информация в поле данных.
• Length (2 байта) — длина заголовка и данных UDP в байтах.
• Checksum (2 байта) — код CRC, вычисленный передающей систе мой. Целевая система использует его для обнаружения ошибок в заголовке UDP, данных и частях заголовка IP.
• Data (переменной длины) — данные, сгенерированные процессом прикладного уровня, номер которого указан в поле Source Port.
Поля Source Port и Destination Port в заголовке UDP выполняют те же функции, что и в заголовке TCP. В поле Length указано количе ство данных, включенных в сообщение UDP. В стандарте UDP использование контрольной суммы не является обязательным. Если она не используется, передающая система заполняет поле Checksum нулями.
По поводу включения кон трольной суммы в сообщения UDP было много споров. В документе RFC 768 указано, что во все системы UDP должна включаться воз можность проверки контрольной суммы, и этот метод обнаружения ошибок действительно используется в большинстве реализаций про токола UDP.
Как и TCP/IP, набор протоколов SPX/IPX фирмы NetWare включает несколько протоколов транспортного уров ня, предоставляющих различные услуги. Интересно, что протокол транспортного уровня SPX (Sequenced Packet Exchange), чаше всего ассоциируемый с IPX, используется гораздо реже, чем NCP (NetWare Core Protocol).
SPX (Sequenced Packet Exchange) — протокол NetWare, ориентиро ванный на соединение. Список предоставляемых им услуг во многом совпадает с аналогичным списком TCP, включая подтверждение при ема пакетов и управление потоком, но используется он гораздо реже. Серверы NetWare используют SPX для обмена информацией между очередями печати, серверами печати и принтерами, а также в специ ализированных приложениях, которым требуются услуги SPX. Напри мер, в Rconsole.
Сообщения SPX (рис) переносятся внутри дейтаграмм IPX.
Функции полей сообщения SPX таковы:
• Connection Control (1 байт) — идентификатор функции сообщения, например, End Of Message или Acknowledgment Required.
• Datastream Type (1 байт) — идентификатор типа информации в поле данных или код, используемый при разрыве соединения.
• Source Connection ID (2 байта) — число, используемое передающей системой для идентификации текущего соединения.
• Destination Connection ID (2 байта) — число, используемое прини мающей системой для идентификации текущего соединения.
• Sequence Number (2 байта) — положение сообщения в последова тельности.
• Acknowledgment Number (2 байта) — величина Sequence Number, которую система ожидает найти в следующем полученном пакете; подтверждает успешное получение всех предыдущих пакетов.
• Allocation Number (2 байта) — число доступных буферов для при ема пакетов на передающей системе. Это поле используется для управления потоком.
• Data (переменной длины) — информация, сгенерированная прило жением или протоколом более высокого уровня.
NCP (NetWare Core Protocol) отвечает за весь трафик, связанный с совместным использованием файлов клиентами и серверами Net Ware, а также выполняет ряд других функций. В результате NCP ис пользуется гораздо чаще, чем SPX.
Широкий спектр применения NCP затрудняет определение его положения в эталонной модели OSI. Уча стие в перемещениях файлов между клиентами и серверами, казалось бы, заставляет отнести этот протокол к транспортному уровню. Но клиенты NetWare используют сообщения NCP для регистрации в де реве NDS (Novell Directory Services), а это функция сеансового уров ня. Мало того, NCP оказывает также услуги представительского и прикладного уровней. И все-таки, сообщения NCP переносятся внут ри IPX-дейтаграмм, а это значит, что он в большей степени относит ся к транспортному уровню.
В отличие от протоколов транспортного уровня SPX и TCP/IP, в NCP используются разные форматы для запросов клиента и ответов сервера. Кроме того, особая форма сообщений NCP — протокол NCPB (NetWare Core Packet Burst) — позволяет системе передавать несколь ко сообщений с единственным подтверждением приема.
Протокол NCPB разработан сравнительно недавно для обхода недостатка NCP, который требует подтверждать получение каждого пакета с данными.
Формат запроса NCP Request:
• Request Type (2 байта) — идентификатор типа запроса.
• Sequence Number (1 байт) — положение сообщения в последова тельности NCP.
• Connection Number Low (1 байт) — номер соединения клиента с сер вером.
• Task Number (1 байт) — уникальное значение, по которому систе мы ассоциируют запросы и ответы.
• Connection Number High (1 байт) — не используется.
• Function (1 байт) — конкретная функция сообщения.
• Subfunction (1 байт) — уточнение функции сообщения.
• Subfunction Length (2 байта) — длина поля данных.
• Data (переменной длины) — информация, необходимая серверу для обработки запроса, например, расположение файла.
Примечание Для описания функции сообщения NCP Request исполь зуются три поля, что может показаться излишним. Но для удовлетво рения потребностей служб, предоставляемых серверами NetWare, не обходимо более 200 сочетаний кодов Function и Subfunction.
Формат запроса NCP Reply:
• Reply/Response Type (2 байта) — тип ответного сообщения: File Server Reply, Burst Mode Protocol или Positive Acknowledgment.
• Sequence Number (1 байт) — положение сообщения в последова тельности NCP.
• Connection Number Low (1 байт) — номер соединения клиента с сер вером.
• Task Number (I байт) — уникальное значение, по которому систе мы ассоциируют запросы и ответы.
• Connection Number High (1 байт) — не используется.
• Completion Code (1 байт) — указывает, был ли связанный с этим ответным сообщением запрос успешно выполнен.
• Connection Status (1 байт) — указывает, активно ли еще соединение между клиентом и сервером.
• Data (переменной длины) — информация, посланная сервером в ответ на запрос.