какие приложения используют udp
ИТ База знаний
Полезно
— Онлайн генератор устойчивых паролей
— Онлайн калькулятор подсетей
— Руководство администратора FreePBX на русском языке
— Руководство администратора Cisco UCM/CME на русском языке
— Руководство администратора по Linux/Unix
Навигация
Серверные решения
Телефония
FreePBX и Asterisk
Настройка программных телефонов
Корпоративные сети
Протоколы и стандарты
Популярные приложения TCP/IP
Онлайн курс по Кибербезопасности
Изучи хакерский майндсет и научись защищать свою инфраструктуру! Самые важные и актуальные знания, которые помогут не только войти в ИБ, но и понять реальное положение дел в индустрии
Вы должны хотя бы знать о некоторых приложениях, которые можно использовать для управления и контроля сети.
Приложение World Wide Web (WWW) используется через веб-браузеры, обращаясь к содержимому, доступному на веб-серверах. Хотя его часто называют приложением для конечного пользователя, вы можете использовать WWW для управления маршрутизатором или коммутатором. Вы включаете функцию веб-сервера в маршрутизаторе или коммутаторе и используете браузер для доступа к маршрутизатору или коммутатору.
Система доменных имен (DNS) позволяет пользователям использовать имена для обозначения компьютеров, при этом DNS используется для поиска соответствующих IP-адресов. DNS также использует модель клиент / сервер, при этом DNS-серверы контролируются сетевым персоналом, а клиентские функции DNS являются частью большинства устройств, использующих TCP / IP сегодня. Клиент просто просит DNS-сервер предоставить IP-адрес, соответствующий заданному имени.
Независимо от того, какой протокол транспортного уровня используется, приложения используют хорошо известный номер порта, чтобы клиенты знали, к какому порту пытаться подключиться. В таблице 2 перечислены несколько популярных приложений и их известные номера портов.
Таблица № 2 Популярные приложения и их известные номера портов
Онлайн курс по Кибербезопасности
Изучи хакерский майндсет и научись защищать свою инфраструктуру! Самые важные и актуальные знания, которые помогут не только войти в ИБ, но и понять реальное положение дел в индустрии
ИТ База знаний
Полезно
— Онлайн генератор устойчивых паролей
— Онлайн калькулятор подсетей
— Руководство администратора FreePBX на русском языке
— Руководство администратора Cisco UCM/CME на русском языке
— Руководство администратора по Linux/Unix
Навигация
Серверные решения
Телефония
FreePBX и Asterisk
Настройка программных телефонов
Корпоративные сети
Протоколы и стандарты
Нужно знать: про TCP и UDP
Онлайн курс по Кибербезопасности
Изучи хакерский майндсет и научись защищать свою инфраструктуру! Самые важные и актуальные знания, которые помогут не только войти в ИБ, но и понять реальное положение дел в индустрии
UDP предоставляет приложениям сервис для обмена сообщениями. В отличие от TCP, UDP не требует установления соединения и не обеспечивает надежности, работы с окнами, переупорядочивания полученных данных и сегментации больших фрагментов данных на нужный размер для передачи. Однако UDP предоставляет некоторые функции TCP, такие как передача данных и мультиплексирование с использованием номеров портов, и делает это с меньшим объемом служебных данных и меньшими затратами на обработку, чем TCP.
Передача данных UDP отличается от передачи данных TCP тем, что не выполняется переупорядочевание или восстановление. Приложения, использующие UDP, толерантны к потерянным данным, или у них есть какой-то прикладной механизм для восстановления потерянных данных. Например, VoIP использует UDP, потому что, если голосовой пакет потерян, к тому времени, когда потеря может быть замечена и пакет будет повторно передан, произойдет слишком большая задержка, и голос будет неразборчивым. Кроме того, запросы DNS используют UDP, потому что пользователь будет повторять операцию, если разрешение DNS не удается. В качестве другого примера, сетевая файловая система (NFS), приложение удаленной файловой системы, выполняет восстановление с помощью кода уровня приложения, поэтому функции UDP приемлемы для NFS.
На рисунке 10 показан формат заголовка UDP. Самое главное, обратите внимание, что заголовок включает поля порта источника и назначения для той же цели, что и TCP. Однако UDP имеет только 8 байтов по сравнению с 20-байтовым заголовком TCP, показанным на рисунке 1-1. UDP требует более короткого заголовка, чем TCP, просто потому, что у UDP меньше работы.
Приложения TCP / IP
Всемирная паутина (WWW) состоит из всех подключенных к Интернету веб-серверов в мире, а также всех подключенных к Интернету хостов с веб-браузерами. Веб-серверы, которые состоят из программного обеспечения веб-сервера, запущенного на компьютере, хранят информацию (в виде веб-страниц), которая может быть полезна для разных людей. Веб-браузер, представляющий собой программное обеспечение, установленное на компьютере конечного пользователя, предоставляет средства для подключения к веб-серверу и отображения веб-страниц, хранящихся на веб-сервере. Хотя большинство людей используют термин «веб-браузер» или просто «браузер«, веб-браузеры также называются веб-клиентами, потому что они получают услугу с веб-сервера.
Чтобы этот процесс работал, необходимо выполнить несколько определенных функций прикладного уровня. Пользователь должен каким-то образом идентифицировать сервер, конкретную веб-страницу и протокол, используемый для получения данных с сервера. Клиент должен найти IP-адрес сервера на основе имени сервера, обычно используя DNS. Клиент должен запросить веб-страницу, которая на самом деле состоит из нескольких отдельных файлов, а сервер должен отправить файлы в веб-браузер. Наконец, для приложений электронной коммерции (электронной коммерции) передача данных, особенно конфиденциальных финансовых данных, должна быть безопасной. В следующих подразделах рассматривается каждая из этих функций.
Унифицированные идентификаторы ресурсов
Чтобы браузер отображал веб-страницу, он должен идентифицировать сервер, на котором находится эта веб-страница, а также другую информацию, которая идентифицирует конкретную веб-страницу. Большинство веб-серверов имеют множество веб-страниц. Например, если вы используете веб-браузер для просмотра www.cisco.com и щелкаете по этой веб-странице, вы увидите другую веб-страницу. Щелкните еще раз, и вы увидите другую веб-страницу. В каждом случае щелчок идентифицирует IP-адрес сервера, а также конкретную веб-страницу, при этом детали в основном скрыты от вас. (Эти интерактивные элементы на веб-странице, которые, в свою очередь, переводят вас на другую веб-страницу, называются ссылками.)
Большинство браузеров поддерживают какой-либо способ просмотра скрытого URI, на который ссылается ссылка. В некоторых браузерах наведите указатель мыши на ссылку, щелкните правой кнопкой мыши и выберите «Свойства». Во всплывающем окне должен отображаться URI, на который будет направлен браузер, если вы нажмете эту ссылку.
В просторечии многие люди используют термины веб-адрес или аналогичные связанные термины Universal Resource Locator (или Uniform Resource Locator [URL]) вместо URI, но URI действительно является правильным формальным термином. Фактически, URL-адрес используется чаще, чем URI, уже много лет. Однако IETF (группа, определяющая TCP / IP) вместе с консорциумом W3C (W3.org, консорциум, разрабатывающий веб-стандарты) предприняли согласованные усилия по стандартизации использования URI в качестве общего термина.
С практической точки зрения, URI, используемые для подключения к веб-серверу, включают три ключевых компонента, как показано на рисунке 11. На рисунке показаны формальные имена полей URI. Что еще более важно для понимания, обратите внимание, что текст перед :// определяет протокол, используемый для подключения к серверу, текст между // и / идентифицирует сервер по имени, а текст после / идентифицирует веб-страницу.
Поиск веб-сервера с помощью DNS
Чтобы собрать воедино несколько концепций, на рисунке 12 показан процесс DNS, инициированный веб-браузером, а также некоторая другая связанная информация. С базовой точки зрения пользователь вводит URI (в данном случае http://www.exempel.com/go/learningnetwork), преобразует имя www.exempel.com в правильный IP-адрес и начинает отправлять пакеты на веб сервер.
Шаги, показанные на рисунке, следующие:
Пример на рисунке 12 показывает, что происходит, когда клиентский хост не знает IP-адрес, связанный с именем хоста, но предприятие знает адрес. Однако хосты могут кэшировать результаты DNS-запросов, так что какое-то время клиенту не нужно запрашивать DNS для разрешения имени. Также DNS-сервер может кэшировать результаты предыдущих DNS-запросов; например, корпоративный DNS-сервер на рисунке 12 обычно не имеет настроенной информации об именах хостов в доменах за пределами этого предприятия, поэтому в этом примере DNS-сервер кэшировал адрес, связанный с именем хоста www.example.com.
Когда локальный DNS не знает адрес, связанный с именем хоста, ему необходимо обратиться за помощью. На рисунке 13 показан пример с тем же клиентом, что и на рисунке 12. В этом случае корпоративный DNS действует как рекурсивный DNS-сервер, отправляя повторяющиеся DNS-сообщения, чтобы идентифицировать авторитетный DNS-сервер.
Шаги, показанные на рисунке, следующие:
Передача файлов по HTTP
После того, как веб-клиент (браузер) создал TCP-соединение с веб-сервером, клиент может начать запрашивать веб-страницу с сервера. Чаще всего для передачи веб-страницы используется протокол HTTP. Протокол прикладного уровня HTTP, определенный в RFC 7230, определяет, как файлы могут передаваться между двумя компьютерами. HTTP был специально создан для передачи файлов между веб-серверами и веб-клиентами.
HTTP определяет несколько команд и ответов, из которых наиболее часто используется запрос HTTP GET. Чтобы получить файл с веб-сервера, клиент отправляет на сервер HTTP-запрос GET с указанием имени файла. Если сервер решает отправить файл, он отправляет ответ HTTP GET с кодом возврата 200 (что означает ОК) вместе с содержимым файла.
Для HTTP-запросов существует множество кодов возврата. Например, если на сервере нет запрошенного файла, он выдает код возврата 404, что означает «файл не найден». Большинство веб-браузеров не показывают конкретные числовые коды возврата HTTP, вместо этого отображая ответ, такой как «страница не найдена», в ответ на получение кода возврата 404.
Веб-страницы обычно состоят из нескольких файлов, называемых объектами. Большинство веб-страниц содержат текст, а также несколько графических изображений, анимированную рекламу и, возможно, видео и звук. Каждый из этих компонентов хранится как отдельный объект (файл) на веб-сервере. Чтобы получить их все, веб-браузер получает первый файл. Этот файл может (и обычно делает) включать ссылки на другие URI, поэтому браузер затем также запрашивает другие объекты. На рисунке 14 показана общая идея, когда браузер получает первый файл, а затем два других.
Как принимающий хост определяет правильное принимающее приложение
Эта лекция завершается обсуждением процесса, с помощью которого хост при получении любого сообщения по любой сети может решить, какая из множества своих прикладных программ должна обрабатывать полученные данные.
В качестве примера рассмотрим хост A, показанный слева на рисунке 15. На хосте открыто три разных окна веб-браузера, каждое из которых использует уникальный TCP-порт. На хосте A также открыт почтовый клиент и окно чата, оба из которых используют TCP. И электронная почта, и чат-приложения используют уникальный номер TCP-порта на хосте A, как показано на рисунке.
В этой части лекции показано несколько примеров того, как протоколы транспортного уровня используют поле номера порта назначения в заголовке TCP или UDP для идентификации принимающего приложения. Например, если значение TCP-порта назначения на рисунке 15 равно 49124, хост A будет знать, что данные предназначены для первого из трех окон веб-браузера.
Прежде чем принимающий хост сможет проверить заголовок TCP или UDP и найти поле порта назначения, он должен сначала обработать внешние заголовки в сообщении. Если входящее сообщение представляет собой кадр Ethernet, который инкапсулирует пакет IPv4, заголовки выглядят так, как показано на рисунке 16.
Заголовок IPv4 имеет аналогичное поле, называемое полем протокола IP. Поле протокола IPv4 имеет стандартный список значений, которые идентифицируют следующий заголовок, с десятичным числом 6, используемым для TCP, и десятичным числом 17, используемым для UDP. В этом случае значение 6 определяет заголовок TCP, следующий за заголовком IPv4. Как только принимающий хост понимает, что заголовок TCP существует, он может обработать поле порта назначения, чтобы определить, какой процесс локального приложения должен получить данные.
Онлайн курс по Кибербезопасности
Изучи хакерский майндсет и научись защищать свою инфраструктуру! Самые важные и актуальные знания, которые помогут не только войти в ИБ, но и понять реальное положение дел в индустрии
Протокол UDP — преимущества, недостатки и применение
А зачем протокол транспортного уровня, если он не обеспечивает надежность доставки выше чем IP, почему нельзя использовать просто IP для передачи данных?
Но на транспортном уровне необходимо указать порт отправителя и порт получателя, что и делает протокол UDP.
Формат заголовка
Формат заголовка udp состоит из 4-х полей:
Преимущества и применение UDP
Преимущество UDP в том, что протокол обеспечивает более высокую скорость работы по сравнению с TCP, так как у него нет накладных расходов на установку и на разрыв соединения.
Ошибки в современных сетях происходят достаточно редко и сетевые приложения способны самостоятельно исправлять такие, редко возникающие ошибки.
Область применения UDP — это системы, которые работают в режиме запрос-ответ и обмениваются между собой короткими сообщениями.
Применение UDP: DNS
В качестве применения UDP рассмотрим систему доменных имен DNS. DNS позволяют определить по доменному имени соответствующий ему IP-адрес. Например к доменному имени www.cisco.com соответствует вот такой IP адрес 184.86.0.170. Система DNS использует протокол UDP, порт 53.
Рассмотрим пример сетевого взаимодействия в DNS. В системе DNS есть сервер, который знает какие IP-адреса соответствуют доменным именам и клиент, который хочет получить такую информацию. Клиент DNS направляет запрос серверу, какой IP у доменного имени www.cisco.com? Сервер DNS получает такой запрос, находит соответствующий IP-адрес и отправляет ответ (184.86.0.170) взаимодействие происходит с использованием протокола UDP и для получения IP-адреса достаточно всего две дейтаграммы.
Если бы для запроса IP-адреса использовался протокол TCP, то необходимо было бы передать гораздо больше сообщений. Перед тем как запрашивать IP-адрес необходимо было бы установить соединение TCP. Для этого нужно 3 сообщения, затем запросить IP-адрес, получить ответ (еще 2 сообщения) и после того, как ответ получен нужно разорвать соединение, для этого нужно 3 или 4 сообщения.
Недостаток UDP
Недостаток UDP в том, что он не обеспечивает надежности передачи данных, поэтому ошибки должно обрабатывать приложение. Рассмотрим, что произойдет, если запрос потерялся. Приложение клиента DNS при отправке запроса (www.cisco.com?) запускает таймер, если в течении какого-то времени ответ не приходит, таймер срабатывает и тот же самый запрос отправляется еще раз.
В этот раз запрос дошел (www.cisco.com) и DNS сервер в ответ отправил нам IP-адрес, который был необходим (184.86.0.170). Даже с учетом того, что произошла потеря данных ip-адрес все равно получен быстрее, чем если бы использовался протокол TCP. Однако существенным недостатком использования UDP является то, что приложение само должно обрабатывать ошибочные ситуации.
Выводы по протоколу UDP
Вступление
Такая архитектура Интернета достаточно правильна для клиент-серверного взаимодействия, когда клиенты могут находиться в частных сетях, а серверы имею глобальный адрес. Но она создает трудности для прямого соединения двух узлов между различными частными сетями. Прямое соединение двух узлов важно для «peer-to-peer» приложений, таких как передача голоса (Skype), получение удаленного доступа к компьютеру (TeamViewer), или онлайн игры.
Один из наиболее эффективных методов для установления peer-to-peer соединения между устройствами находящимися в различных частных сетях называется «hole punching». Этот техника чаще всего используется с приложениями на основе UDP протокола.
Но если вашему приложению требуется гарантированная доставка данных, например, вы передаете файлы между компьютерами, то при использовании UDP появится множество трудностей, связанных с тем, что UDP не является протоколом гарантированной доставки и не обеспечивает доставку пакетов по порядку, в отличие от TCP протокола.
В таком случае, для обеспечения гарантированной доставки пакетов, требуется реализовать протокол прикладного уровня, обеспечивающий необходимую функциональность и работающий поверх UDP.
Сразу хочу заметить, что существует техника TCP hole punching, для установления TCP соединений между узлами в разных частных сетях, но ввиду отсутствия поддержки её многими NAT устройствами она обычно не рассматривается как основной способ соединения таких узлов.
Далее в этой статье я буду рассматривать только реализацию протокола гарантированной доставки. Реализация техники UDP hole punching будет описана в следующих статьях.
Требования к протоколу
Для понимания данных требований, давайте рассмотрим временные диаграммы передачи данных между двумя узлами сети по протоколам TCP и UDP. Пусть в обоих случаях у нас будет потерян один пакет.
UDP не предпринимает никаких шагов по обнаружению потерь. Контроль ошибок передачи в UDP протоколе полностью возлагается на приложение.
Обнаружение ошибок в TCP протоколе достигается благодаря установке соединения с конечным узлом, сохранению состояния этого соединения, указанию номера отправленных байт в каждом заголовке пакета, и уведомлениях о получениях с помощью номера подтверждения «acknowledge number».
Дополнительно, для повышения производительности (т.е. отправки более одного сегмента без получения подтверждения) TCP протокол использует так называемое окно передачи — число байт данных которые отправитель сегмента ожидает принять.
Более подробно с TCP протоколом можно ознакомиться в rfc 793, с UDP в rfc 768, где они, собственно говоря, и определены.
Заголовок Reliable UDP
Структура заголовка Reliable UDP достаточно простая:
Общие принципы работы протокола
Так как Reliable UDP ориентирован на гарантированную передачу сообщения между двумя узлами, он должен уметь устанавливать соединение с другой стороной. Для установки соединения сторона-отправитель посылает пакет с флагом FirstPacket, ответ на который будет означать установку соединения. Все ответные пакеты, или, по-другому, пакеты подтверждения, всегда выставляют значение поля PacketNumber на единицу больше, чем самое большое значение PacketNumber у успешно пришедших пакетов. В поле Options для первого отправленного пакета записывается размер сообщения.
Для завершения соединения используется похожий механизм. В последнем пакете сообщения устанавливается флаг LastPacket. В ответном пакете указывается номер последнего пакета + 1, что для приёмной стороны означает успешную доставку сообщения.
Когда соединение установлено, начинается передача данных. Данные передаются блоками пакетов. Каждый блок, кроме последнего, содержит фиксированное количество пакетов. Оно равно размеру окна приема/передачи. Последний блок данных может иметь меньшее количество пакетов. После отправки каждого блока, сторона-отправитель ожидает подтверждения о доставке, либо запроса на повторную доставку потерянных пакетов, оставляя открытым окно приема/передачи для получения ответов. После получения подтверждения о доставке блока, окно прием/передачи сдвигается и отправляется следующий блок данных.
Сторона-получатель принимает пакеты. Каждый пакет проверяется на попадание в окно передачи. Не попадающие в окно пакеты и дубликаты отсеиваются. Т.к. размер окна сторого фиксирован и одинаков у получателя и у отправителя, то в случае доставки блока пакетов без потерь, окно сдвигается для приема пакетов следующего блока данных и отправляется подтверждение о доставке. Если окно не заполнится за установленный рабочим таймером период, то будет запущена проверка на то, какие пакеты не были доставлены и будут отправлены запросы на повторную доставку.
Тайм-ауты и таймеры протокола
Существует несколько причин, по которым не может быть установлено соединение. Например, если принимающая сторона вне сети. В таком случае, при попытке установить соединение, соединение будет закрыто по тайм-ауту. В реализации Reliable UDP используются два таймера для установки тайм-аутов. Первый, рабочий таймер, служит для ожидания ответа от удаленного хоста. Если он срабатывает на стороне-отправителе, то выполняется повторная отправка последнего отправленного пакета. Если же таймер срабатывает у получателя, то выполняется проверка на потерянные пакеты и отправляются запросы на повторную доставку.
Второй таймер – необходим для закрытия соединения в случае отсутствия связи между узлами. Для стороны-отправителя он запускается сразу после срабатывания рабочего таймера, и ожидает ответа от удаленного узла. В случае отсутствия ответа за установленный период – соединение завершается и ресурсы освобождаются. Для стороны-получателя, таймер закрытия соединения запускается после двойного срабатывания рабочего таймера. Это необходимо для страховки от потери пакета подтверждения. При срабатывании таймера, также завершается соединение и высвобождаются ресурсы.
Диаграмма состояний передачи Reliable UDP
Принципы работы протокола реализованы в конечном автомате, каждое состояние которого отвечает за определенную логику обработки пакетов.
Диаграмма состояний Reliable UDP:
Closed – в действительности не является состоянием, это стартовая и конечная точка для автомата. За состояние Closed принимается блок управления передачей, который, реализуя асинхронный UDP сервер, перенаправляет пакеты в соответствующие соединения и запускает обработку состояний.
FirstPacketSending – начальное состояние, в котором находится исходящее соединение при отправке сообщения.
В этом состоянии отправляется первый пакет для обычных сообщений. Для сообщений без подтверждения отправки, это единственное состояние – в нем происходит отправка всего сообщения.
SendingCycle – основное состояния для передачи пакетов сообщения.
Переход в него из состояния FirstPacketSending осуществляется после отправки первого пакета сообщения. Именно в это состояние приходят все подтверждения и запросы на повторные передачи. Выход из него возможен в двух случаях – в случае успешной доставки сообщения или по тайм-ауту.
FirstPacketReceived – начальное состояние для получателя сообщения.
В нем проверяется корректность начала передачи, создаются необходимые структуры, и отправляется подтверждение о приеме первого пакета.
Для сообщения, состоящего из единственного пакета и отправленного без использования подтверждения доставки – это единственное состояние. После обработки такого сообщения соединение закрывается.
Assembling – основное состояние для приема пакетов сообщения.
В нем производится запись пакетов во временное хранилище, проверка на отсутствие потерь пакетов, отправка подтверждений о доставке блока пакетов и сообщения целиком, и отправка запросов на повторную доставку потерянных пакетов. В случае успешного получения всего сообщения – соединение переходит в состояние Completed, иначе выполняется выход по тайм-ауту.
Completed – закрытие соединения в случае успешного получения всего сообщения.
Данное состояние необходимо для сборки сообщения и для случая, когда подтверждение о доставке сообщения было потеряно по пути к отправителю. Выход из этого состояния производится по тайм-ауту, но соединение считается успешно закрытым.
Глубже в код. Блок управления передачей
Глубже в код. Состояния
Состояния реализуют конечный автомат протокола Reliable UDP, в котором происходит основная обработка пакетов. Абстрактный класс ReliableUdpState предоставляет интерфейс для состояния:
Всю логику работы протокола реализуют представленные выше классы, совместно со вспомогательным классом, предоставляющим статические методы, такие как, например, построения заголовка ReliableUdp из connection record.
Далее будут рассмотрены в подробностях реализации методов интерфейса, определяющих основные алгоритмы работы протокола.
Метод DisposeByTimeout
Метод ProcessPackets
Метод ProcessPackets отвечает за дополнительную обработку пакета или пакетов. Вызывается напрямую, либо через таймер ожидания пакетов.
В состоянии Assembling метод переопределен и отвечает за проверку потерянных пакетов и переход в состояние Completed, в случае получения последнего пакета и прохождения успешной проверки
Метод ReceivePacket
Метод SendPacket
Глубже в код. Создание и установление соединений
Глубже в код. Закрытие соединения по тайм-ауту
Периоды таймера задаются при создании соединения. По умолчанию ShortTimerPeriod равен 5 секундам. В примере он установлен в 1,5 секунды.
У входящего соединения таймер запускается после получения последнего дошедшего пакета данных, это происходит в методе ReceivePacket состояния Assembling
Переменная TimerSecondTry установилась в true. Данная переменная отвечает за повторный перезапуск рабочего таймер.
Со стороны отправителя тоже срабатывает рабочий таймер и повторно отсылается последний отправленный пакет.
Период ожидания таймера закрытия соединения равен 30 секундам по-умолчанию.
Через непродолжительное время, повторно срабатывает рабочий таймер на стороне получателя, вновь производится отправка запросов, после чего запускается таймер закрытия соединения у входящего соединения
По срабатыванию таймеров закрытия все ресурсы обоих connection record освобождаются. Отправитель сообщает о неудачной доставке вышестоящему приложению (см. API Reliable UDP).
Глубже в код. Восстановление передачи данных
API Reliable UDP
Для взаимодействия с протоколом передачи данных имеется открытый класс Reliable Udp, являющийся оберткой над блоком управления передачей. Вот наиболее важные члены класса:
Получение сообщения осуществляется по подписке. Сигнатура делегата для метода обратного вызова:
Для подписки на конкретный тип сообщений и/или на конкретного отправителя используются два необязательных параметра: ReliableUdpMessageTypes messageType и IPEndPoint ipEndPoint.
Отправка сообщения осуществляется асинхронного, для этого в протоколе реализована асинхронная модель программирования :
Результат отправки сообщения будет true – если сообщение успешно дошло до получателя и false – если соединение было закрыто по тайм-ауту:
Заключение
Многое не было описано в рамках данной статьи. Механизмы согласования потоков, обработка исключений и ошибок, реализация асинхронных методов отправки сообщения. Но ядро протокола, описание логики обработки пакетов, установка соединения и отработка тайм-аутов, должны проясниться для Вас.
Спасибо за внимание, жду Ваших комментариев и замечаний.
P.S. Для тех, кто интересуется подробностями или просто хочет протестировать протокол, ссылка на проект на GitHube:
Проект Reliable UDP
Полезные ссылки и статьи
Update: Спасибо mayorovp и sidristij за идею добавления task’а к интерфейсу. Совместимость библиотеки со старыми ОС не нарушается, т.к. 4-ый фреймворк поддерживает и XP и 2003 server.