Можно ли организовать UDP соединение с несколькими удаленными хостами, используя один и тот же порт, но разные сокеты.

Идея была такая:

1) выставить опцию SO_REUSEADDR
2) сделать bind на порт
3) вызвать connect с адресом удаленного хоста.

Однако не работает, пакеты от удаленного хоста не доходят до сокета.
У Стивенска поэтому поводу написано довольно мутно:

"If, in the case of a unicast address, there are multiple sockets that match the datagram, which one of the sockets will receive the datagram is implementation dependent".

Когда создаю два сокета с одни портом, но без коннекта, работает как и должно: только один из них получает пакет.
Однако когда оба связаны с удаленным хостом с помощью connect, вроде только один из них должен "match the datagram", но, увы, ни до одного датаграмма не доходит.

Так и должно быть (пишу все под winsock) ?



Это сообщение отредактировал(а) chekist - 18.7.2009, 11:48

Я нечто подобное пробовал на практике:
----------------------------------------------------------
Запустил UDP серверок, законектил UDP клиента к нему, а затем начал конектить копии UDP клиентов к полученому "эфимерному"  порту (уже налаженого соединения) , и первый клиент начал работать как сервер, - начал получать все пакеты от всех клиентов.
Таким же способом можно конектиться к любому UDP клиенту, главное, чтобы клиент первоначально создал соединение с сервером и все клиенты в сети должны знать обратный порт и IP клиента.
------
Надеюсь в тему.....

Вроде как натыкался в MSDN, что в этом случае поведение recv не определено и для разрешения таких ситуаций вводили SO_EXCLUSIVEADDRUSE. 
  А что мешает сделать обертку к сокету,   которая получает ото всех пакеты, и перераспределяет внутри проги как тебе нужно?

Vsts, 

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

В MSDN про SO_REUSEADDR написано следующее


Но непонятно, речь идет о любом протоколе, или только о connection-oriented (TCP).

Вот, нашел.Это тоже в MSDN написано:
In the case where the first bind sets no options or SO_REUSEADDR, and the second bind performs a SO_REUSEADDR, the second socket has overtaken the port and behavior regarding which socket will receive packets is undetermined. SO_EXCLUSIVEADDRUSE was introduced to address this situation.

в словосочетании UDP есть слово дайтаграмм. Т.е. данный уровень не обеспечивает коннекта. Он обеспечивает ОТПРАВКУ ваших данных и ВСЁ. Придут или не прийдут до адресата - ваши проблемы.

Это минус с сточки зрения достоверности канала.
Это плюс с точки зрения экономии ресурсов (можно на одном сокете обеспечить как приём так и отпревку пакетов ЭННОМУ кол-ву абонентов. Т.е. нечто своего аля TCP над одним сокетом). Более того можно спокойно обеспечить масштабируемость такого решения.

Обычно на стороне сервака(тот кто предоставляет ресурсы) делают прослушку на фиксированном(ых) сокетах. На стороне клиента (тот кто юзает ресурсы сервака) делают бродкаст на известный сокет. В случае отзыва - соединяемся. В случае тишины - повторяем несколько раз и ищем мосты в другие подсети. И т.д. это класика так сказать. Можно делать более интересные схемы - ну тут от задач пляшут.


удачи Вам
(круглый)