Протоколы связи в UDP - PullRequest
Новая
       19

Протоколы связи в UDP

2 голосов
/ 04 мая 2010

Через много часов я обнаружил, что данному серверу udp необходимы следующие шаги для успешного общения:

1 - Отправить «Начальное сообщение» на данный порт
2- Подождите, чтобы получить от сервера на любой порт
3- Тогда выделенный вам порт для отправки дальнейших данных на сервер равен порту, который вы получили на нем + 1

Поэтому я спрашиваю, является ли этот тип известным протоколом / подтверждением связи, или он предназначен только для этого сервера ??

PS: Все вышеперечисленное было в сокете udp в C #
PS: относится к предыдущему вопросу: О C # UDP Sockets

Спасибо

Ответы [ 2 ]

2 голосов
/ 04 мая 2010

Сервер фактически прослушивает «хорошо известный порт», а затем переключает последующую связь на выделенный порт для каждого клиента. Требование клиента отправить порт + 1 немного странно 

Client 192.168.0.1 - port 12121   ------------------------> Server 192.168.0.2 - port 5050
Client 192.168.0.1 - port 12121   <------------------------ Server 192.168.0.2 - port 23232
Client 192.168.0.1 - port 12121   ------------------------> Server 192.168.0.2 - port 23232 + 1
                                  <------------------------ Server 192.168.0.2 - port 23232
                                  ------------------------> Server 192.168.0.2 - port 23232 + 1

Сервер, вероятно, делает это, чтобы ему не приходилось демультиплексировать входящие данные клиента на основе адреса / порта клиента. Это немного более эффективно (как правило), а также имеет некоторые преимущества, в зависимости от конструкции сервера, так как на сервере есть «выделенный» сокет для вас, что означает, что если они выполняют перекрывающийся ввод-вывод затем сокет остается неизменным в течение всего периода связи с вами, что может упростить и повысить эффективность сопоставления данных с сокетом (таким образом, они могут, вероятно, избежать любых поисков или блокировок для обработки каждой дейтаграммы). В любом случае, этого достаточно (см. здесь , если вы хотите знать, почему I делает это так).

С вашей точки зрения, как клиента (и я предполагаю асинхронные сокеты здесь), вам нужно сначала Bind() ваш локальный сокет (просто используйте INADDR_ANY и 0, чтобы ОС могла выбрать порт для затем вы) RecvFrom() на сокете (так что нет никакой разницы между отправкой данных на сервер на этом сокете и отправкой данных обратно перед выпуском recv). Затем введите SendTo() для «хорошо известного порта» сервера. Затем сервер отправит вам некоторые данные, а ваш RecvFrom() вернет вам данные и адрес, с которого сервер отправил вам. Затем вы можете взять этот адрес, добавить его в порт, сохранить этот адрес и с этого момента выдавать SendTo() s на этот новый адрес отправки, продолжая при этом выдавать RecvFrom() s для чтения данных сервера; или вы могли бы сделать что-нибудь умное с Connect(), чтобы привязать удаленный конец сокета к серверу 'send to address' и просто использовать с этого момента Write() и RecvFrom().

2 голосов
/ 04 мая 2010

Специального «рукопожатия» для UDP не существует - каждая служба UDP, если она нужна, указывает свою собственную. Однако обычно сервер не ожидает, что клиент сможет одновременно прослушивать все свои порты. Если вы имеете в виду, что клиент ожидает сообщение от любого порта на сервере, на порт, с которого клиент отправил стартовое сообщение, то это имеет гораздо больше смысла - и очень близко к тому, как работает TFTP. (Единственное отличие, которое я вижу до сих пор, состоит в том, что TFTP не выполняет "+ 1".)

...