Top.Mail.Ru
Мастера DELPHI, Delphi programming community Титульная страница Поиск, карта сайта Написать письмо 
| Новости | Поиск | FAQ | Статьи | Книги | Новости VCL |
| Форумы ЧАТ | Орешник | KOL и MCK |
Форумы -» Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

UDP-сервер, принимающий пакеты по всем интерфейсам


Пробегал2... ©   (2008-05-12 20:42:00) 

Читаю статью Антона Григорьева - http://www.delphikingdom.com/asp/viewitem.asp?catalogid=1021#10 - и не понимаю как сделать UDP-сервер, который принимает соединения по всем интерфейсам. Написано следующее:

"С серверами всё несколько сложнее. Система привязывает сокет UDP-сервера к адресу, он ожидает получения пакета. В этот момент система не имеет никакой информации о том, с какими узлами будет вестись обмен через данный сокет, и может выбрать не тот адрес, который нужен. Поэтому сокеты UDP-серверов, работающих в подобных системах, должны явно привязываться к нужному адресу. Сокеты TCP-серверов, находящиеся в режиме ожидания и имеющие адрес InAddr_Any, допускают подключение к ним по любому сетевому интерфейсу, который имеется в системе"

Для TCP понятно существуют функции Listen и Accept, которые легко использовать и на каждого клиента приходится по своему сокету, а основной сокет в Listen-режиме принимает все запросы установления подключений по всеи интерфейсам, если создан с привязкой InAddr_Any.

Но как реализовать это для UDP?! Не могу понять, а в статье этот пункт не освещен...

P.S. Как я понял по статье, если создать UDP-сокет с привязкой InAddr_Any, то при первой же отправке SendTo будет привязан к конкретному интерфейсу и с других интерфейсов пакеты получать не будет...


Anatoly Podgoretsky   (2008-05-14 14:59:00) [1]

> Пробегал2...  (14.05.2008 14:43:13)  [13]

Очень просто будет работать, как и положено по RFC - if:port


Пробегал2...   (2008-05-14 14:43:00) [2]

Сергей М. ©   (14.05.08 14:30) [12]
Не больше часу времени, уверяю


значит ты уже изучил. Расскажи, тогда, пожалуйста ;)

Я думаю они делают обыкновенную привязку к InAddr_Any и не парятся...

Но вот как это будет работать на двух сетевых картах... Нужно иметь две сетевые карты ;)


Сергей М.   (2008-05-14 14:30:00) [3]


> Пробегал2...   (14.05.08 14:07) [11]


> там же такая иерархия классов, очень много времени надо
> убить


Не больше часу времени, уверяю).. Что гораздо меньше времени, прошедшего с момента, когда ты запостил сюда свои сомнения, и по сей момент


Пробегал2...   (2008-05-14 14:07:00) [4]

Сергей М. ©   (14.05.08 13:36) [10]

нет не исследовал, там же такая иерархия классов, очень много времени надо убить, которого нету.

В общем, судя по всему, Антон Григорьев ошибся и в его статье ошибка. Он сам не знает как будет себя все вести при двух сетевых картах, информацию черпал скудную из разных статей MSDN. Видимо, что-то не так понял.

Никакой привязки при SendTo / RecvFrom не происходит, кроме привязки ко всем интерфейсам. То, что и нужно собственно...


Сергей М.   (2008-05-14 13:36:00) [5]


> Пробегал2...   (14.05.08 13:16) [9]


А ты исследовал на эту тему код хотя бы того же IdUDPServer ?


Пробегал2...   (2008-05-14 13:16:00) [6]

Сергей М. ©   (14.05.08 11:42) [8]
Как видишь, никакой привязки к интерфейсу при этом не происходит


тут говорится лишь о том, что если не выполнена функция Connect - то нет никаких ограничений по адресу источника. И это действительно так, если бы функция connect была выполнена - то был бы включен режим фильтрации по адресу источника.

Но отсутствие ограничений по адресу источника не означает, что нет привязки к локальному интерфейсу.

Собственно, я уверен что ты про RecvFrom найдешь тоже самое. После его использование тоже никаких ограничений на адрес источника не накладывается, оно накладывается только функцией connect.


Сергей М.   (2008-05-14 11:42:00) [7]

UDP recv():

If unconnected, the socket must be bound, and there are no source address restrictions on datagrams received.

Как видишь, никакой привязки к интерфейсу при этом не происходит.
А то что адрес отправителя при этом не известен, это уже другой вопрос.


Пробегал2...   (2008-05-13 21:55:00) [8]

Сергей М. ©   (13.05.08 15:00) [6]
Отсюда напрашивается и решение - на серверной стороне вместо ф-ций recvfrom() и sendto() использовать, соотв-но, recv() и send()


это как это?!

Использование функций без постфикса From возможно только ПОСЛЕ использования функции Connect, который связывает сокет с УДАЛЕННЫМ портом. Для TCP это инициализирует подключение, для UDP включает режим фильтрации для этого сокета по приему пакетов только от указанного удаленного порта...

Поэтому предложение бредово:

1) использовать recv без предварительного connect невозможно... Скорее всего не сработает, но в любом случае ты не будешь знать ОТ КОГО пришло сообщение

2) использовать send без предварительного connect невозможно. Система не будет знать КУДА посылать пакет. Это или указывается в функции SendTo, или отправитель указывается в функции Connect

3) если использовать функцию connect перед recv / send - это приведет к точно такой же привязке к интерфейсу локальному, а еще плюс и привязку к удаленному порту.

Что это за сервер, который работает только с одним удаленным клиентом?!?!


Сергей М.   (2008-05-13 15:00:00) [9]


> сокеты UDP-серверов, работающих в подобных системах, должны
> явно привязываться к нужному адресу


Не должны и не обязаны, но вправе и могут.

Фактическая привязка к конкретному интерфейсу UDP-гнезда, которое было забиндено к INADDR_ANY,  происходит при первом же вызове любой из ф-ций connect(), recvfrom(), sendto()

Отсюда напрашивается и решение - на серверной стороне вместо ф-ций recvfrom() и sendto() использовать, соотв-но, recv() и send()


Пробегал2...   (2008-05-13 14:16:00) [10]

неужели никто не знает...


Пробегал2...   (2008-05-12 21:05:00) [11]

хотя по NETSTAT видна куча UDP-сокетов, висящих на 0.0.0.0 интерфейсе (то бишь этот InAddr_Any):

TCP    127.0.0.1:1025         0.0.0.0:0              LISTENING
TCP    192.168.0.1:139        0.0.0.0:0              LISTENING
UDP    0.0.0.0:445            *:*
UDP    0.0.0.0:500            *:*
UDP    0.0.0.0:1038           *:*
UDP    0.0.0.0:1040           *:*
UDP    0.0.0.0:1054           *:*
UDP    0.0.0.0:1056           *:*
UDP    0.0.0.0:1065           *:*
UDP    0.0.0.0:1066           *:*
UDP    0.0.0.0:1067           *:*
UDP    0.0.0.0:1068           *:*
UDP    0.0.0.0:1069           *:*
UDP    0.0.0.0:1070           *:*
UDP    0.0.0.0:4500           *:*


где ошибка, в статье Антона или где?


User1   (2008-05-12 20:58:00) [12]


> Пробегал2...   (12.05.08 20:53) [2]

:o)


Пробегал2...   (2008-05-12 20:53:00) [13]

спасибо за совет, очень полезно.


User1   (2008-05-12 20:48:00) [14]


> Пробегал2...   (12.05.08 20:42)  

Читай внимательно !


Наверх

Титульная страница Поиск, карта сайта Написать письмо