Так же, как и в TCP, в UDP индивидуальные соединения различаются номерами портов. Номера портов от 0 до 1023 отведены для зарезервированных приложений. Номера портов от 1024 до 65536 доступны для ваших приложений. Следущая таблица показывает номера портов, используемых наиболее известными приложениями.
Port |
Description |
53 |
Domain Name System |
69 |
Trivial File Transfer Protocol |
111 |
Remote Procedure Call |
137 |
NetBIOS name service |
138 |
NetBIOS datagram |
161 |
Simple Network Management Protocol |
Многие приложения резервируют как TCP-, так и UDP-порты, хотя на практике используется либо тот, либо другой тип соединений.
Особенностью разработки приложений на основе протокола TCP является необходимость поддерживать буферы данных. Так как TCP обещает сохранить целостность данных, он вынужден хранить данные в буфере (на стороне отправителя) до тех пор, пока не будет получено подтверждение о их получении. Получатель также вынужден использовать временный буфер, чтобы убедиться, что последовательность полученных пакетов не нарушена.
Подсистема Windows, управляющая TCP, отвечает за обмен данными между вашим приложением и сетевым устройством. Перед тем, как отправить данные получателю, система накапливает их в буфере. Затем она пытается отправить все содержимое буфера в рамках одного пакета (Data1 и Data 2 на рисунке ниже).
В этом сценарии возможна ситуация, когда индивидуальные сообщения от разных приложений могут оказаться в одном буфере. Для программиста это означает, что количество блоков данных на стороне отправителя может не совпадать с с количеством блоков на стороне получателя. При первом знакомстве такой поворот событий кажется неожиданным и способен смутить. Задача выделения Data1 и Data2 из общего пакета возлагается на сетевую программу на стороне получателя. Так как подсистема TCP стирает границы между блоками данных, то логика сетевой программы должна быть более сложной. Существует два способа решения этой задачи:
¨ Создать протокол, который вводит реакции на каждый отдельный блок данных.
¨ Разработать систему маркировки для различения границ между отдельными сообщениями.
Наиболее часто используют первый способ. При реализации работы с FTP-протоколами часто прибегают ко второму способу. При этом клиентское приложение посылает на сервер одно сообщение (один блок данных) и ждет ответа, подтверждающего его получение.
Протокол UDP был создан для того, чтобы устранить проблему границ между блоками данных. Этот протокол не нуждается в буферах накопления, так как каждое сообщение (блок данных) посылается в виде отдельного пакета. Аналогично этому, каждый полученный пакет тут же передается приложению в виде одного сообщения.
Недостатком протокола UDP является тот факт, что он не гарантирует надежную доставку данных. Эту проблему должно решать сетевое приложение. Программа на стороне отправителя должна убедиться, что отправленный пакет получен. Одним из способов решения этой проблемы является ожидание ответа на каждый посланный пакет (метод command/response). Если ответ не пришел, то программа считает, что посланный пакет утерян. Процесс передачи пакета делится на четыре шага:
1. Отсыл данных удаленному получателю,
2. Запуск таймера, настроенного на определенный квант времени,
3. Ожидание ответа. Если ответ пришел, то таймер сбрасывается и выполнение программы возобновляется.
4. Если квант времени истек, а подтверждение не пришло, то вся процедура повторяется.
Если число попыток (the retry count) превзошло определенное количество, то делается вывод, что связь с узлом невозможна. Алгоритм проверки целостности хоть и прост, но потребует усилий, поэтому протокол TCP считается более приемлемым.
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.