Как различать два различных клиента UDP на том же IP-адресе?
Я пишу сервер UDP, который является первым для меня; я только сделал немного связи TCP. И я испытываю затруднения при выяснении точно, как различать, который - пользователь, который, так как UDP имеет дело только с пакетами, а не соединениями, и я поэтому не могу сказать точно, кем я общаюсь с.
Вот псевдокод моего текущего цикла сервера:
DatagramPacket p;
socket.receive(p); // now p contains the user's IP and port, and the data
int key = getKey(p);
if(key == 0) { // connection request
key = makeKey(p);
clients.add(key, p.ip);
send(p.ip, p.port, key); // give the user his key
} else { // user has a key
// verify key belongs to that IP address
// lookup the user's session data based on the key
// react to the packet in the context of the session
}
При разработке этого я имел в виду эти точки:
- Многочисленные пользователи могут существовать на том же IP-адресе, из-за присутствия маршрутизаторов, поэтому у пользователей должен быть отдельный идентификационный ключ.
- Пакеты могут имитироваться, таким образом, ключ должен быть проверен по своему исходному IP-адресу и проигнорирован, если другой IP пытается использовать ключ.
- Исходящий порт на стороне клиента мог бы измениться среди пакетов.
То третье предположение корректно, или я могу просто предположить что один пользователь = одна комбинация IP+port? Это обычно делается, или я должен продолжить создавать специальный ключ как, я в настоящее время делаю?
Я не абсолютно ясен о том, как TCP согласовывает соединение поэтому, если Вы думаете, что я должен смоделировать его прочь TCP, затем свяжите меня с хорошим учебным руководством или чем-то на путанице SYN/SYNACK/ACK TCP.
Также отметьте, у меня действительно есть условие для повторной отправки ключа, если IP отправляет 0, и тот IP уже имеет незаконченный ключ; я опустил его для хранения отрывка простым. Я понимаю, что UDP, как гарантируют, не прибудет, и я планирую добавить, что надежность к основной пакетной обработке кодирует позже также.
3 ответа
Заголовки UDP пакетов имеют порт источника, который обычно используется как порт ответа. Если он не используется, он должен быть нулевым, и тогда протоколу более высокого уровня предстоит выяснить, как координировать действия запроса-ответа с несколькими клиентами.
* Исходящий порт на стороне клиента может изменяться среди пакетов.Правильно ли это третье предположение
Нет, если клиент продолжает использовать тот же исходящий сокет. Отправка первой дейтаграммы вызовет локальную привязку, поэтому с этого момента сокет будет на фиксированном локальном порту.
Ваши вопросы - это лишь верхушка айсберга WRT списка проблем, о которых вам нужно знать при использовании UDP. Следует ожидать, что маршрутизаторы NAT не смогут обеспечить значимую пересылку разработанного вами протокола UDP. TCP работает, потому что маршрутизаторы понимают конечный автомат TCP и хранят состояние подключения каждого сеанса, поэтому они знают, как его пересылать. Они не будут иметь представления о том, как работает ваш собственный протокол UDP. Устройства NAT включают специальные обработчики протоколов для хорошо известных приложений UDP.
Если отправитель привязан к исходному порту или интерфейсу, исходные порты отправителя остаются постоянными до тех пор, пока не будут отсоединены.
С помощью UDP вы можете привязать обоих одноранговых узлов к известному исходному порту для (dst) входящих и / или (src) исходящих сообщений. Для клиент-серверных приложений обычно требуется, чтобы клиент привязался к динамическому исходному порту, чтобы несколько клиентов могли сосуществовать в одной клиентской системе. Затем сервер может ответить клиенту, используя динамический порт источника, предоставленный через порт src из запроса, который используется в качестве порта назначения в ответе. Использование известного порта для одноранговых узлов позволяет настроить пересылку UDP в устройствах NAT.
ex клиент / сервер с сервером на известном порте 3000
клиент связывается со случайным портом (1234), но знает, что сервер прослушивает порт 3000. клиент (src 1234) -> сервер (dst 3000) ) сервер (dst 1234) -> клиент (src 3000) ...
Если компьютер имеет несколько интерфейсов, следует ожидать, что вам потребуется либо явно привязать слушателя или отправителя к определенному IP-адресу, либо иметь возможность обрабатывать запросы и ответы от однорангового узла, отправляемые и получаемые от случайного IP-адреса на основе прихоти таблицы маршрутизации компьютеров. Если вы решите привязать запросы к определенному интерфейсу, вам необходимо знать о таблице маршрутизации, если сообщения из многосетевой системы должны проходить через другой локальный интерфейс для доставки. Например, если вы привязываете сокет UDP к 127.0.0.1, вы, очевидно, не можете использовать его для отправки на какие-либо маршрутизируемые IP-адреса в Интернете.
С точки зрения конструкции протокола, обычно в полезных данных UDP используются поля идентификатора сеанса и последовательности, чтобы одноранговые узлы могли отслеживать сеансы и отдельные обмены.
Существует целый ряд проблем фрагментации, сосуществования NAT, безопасности и перегрузки, о которых необходимо знать, чтобы успешно разработать надежный протокол UDP. Я не рекомендую это делать без крайней необходимости.