Как организовать двунаправленную передачу данных по UDP на одной машине, на одном порту? То есть два приложения биндят сокеты на один и тот же порт, оба шлют данные, оба принимают....У меня получается что, кто-то один читает все — и свои данные и те которые отпраляет второе приложение... Пробовал и отсылать пакет обратно, и recv(..MSG_PEEK..) все равно... Может кто-нить помочь?

Здравствуйте, starick, Вы писали:

S>Как организовать двунаправленную передачу данных по UDP на одной машине, на одном порту? То есть два приложения биндят сокеты на один и тот же порт, оба шлют данные, оба принимают....У меня получается что, кто-то один читает все — и свои данные и те которые отпраляет второе приложение... Пробовал и отсылать пакет обратно, и recv(..MSG_PEEK..) все равно... Может кто-нить помочь?

изначально ip-адрес:порт однозначно определяют приложение (см.например RFC1700 здесь). ты же пытаешься на эту одназначность повесить два сокета для приема дайтаграмм (практически это два сервера обработки). вот и ответь на вопрос — а по какому признаку winsock должен разруливать пакеты между ними (а если их будет очень много ) поэтому имеешь то, что имеешь — дайтаграммы отдаются только в один из них.
подбирай другое решение

Здравствуйте, SCS, Вы писали:

S>>Как организовать двунаправленную передачу данных по UDP на одной машине, на одном порту? То есть два приложения биндят сокеты на один и тот же порт, оба шлют данные, оба принимают....У меня получается что, кто-то один читает все — и свои данные и те которые отпраляет второе приложение... Пробовал и отсылать пакет обратно, и recv(..MSG_PEEK..) все равно... Может кто-нить помочь?

SCS>изначально ip-адрес:порт однозначно определяют приложение (см.например RFC1700 здесь). ты же пытаешься на эту одназначность повесить два сокета для приема дайтаграмм (практически это два сервера обработки). вот и ответь на вопрос — а по какому признаку

ИМХО, ты не прав. Зачем тогда по твоему придумана опция SO_REUSEADDR?

>winsock должен разруливать пакеты между ними (а если их будет очень много ) поэтому имеешь то, что имеешь — дайтаграммы отдаются только в один из них.

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

SCS>подбирай другое решение

Здравствуйте, Lexey, Вы писали:
L>Зачем тогда по твоему придумана опция SO_REUSEADDR?
а как он без этой включенной опции смог бы использовать порт повторно ? она должна стоять.

L>Винсоку и незачем ничего разруливать. Ему достаточно кидать приходящие дэйтаграммы в несколько буферов (по числу слушающих приложений). Ничего сложного я тут не вижу.
это справедливо для broadcast и multicast дэйтаграмм. здесь же требуется, как я понял, unicast. и поскольку адрес отправителя один и тот же (не уникален), то и возникла проблема

Здравствуйте, SCS, Вы писали:

SCS>изначально ip-адрес:порт однозначно определяют приложение (см.например RFC1700 здесь). ты же пытаешься на эту одназначность повесить два сокета для приема дайтаграмм (практически это два сервера обработки). вот и ответь на вопрос — а по какому признаку winsock должен разруливать пакеты между ними (а если их будет очень много ) поэтому имеешь то, что имеешь — дайтаграммы отдаются только в один из них.

В WinSock для каждого сокета выделяется собственный буфер? В МСДН везде упоминается некий "системный буфер"... Так вот я надеялся, что рассмотрев пакет, поняв что это тот пакет, который я же и отправлял и оставив его в буфере сокета на некоторое время (то есть первое приложение "засыпает") второе приложение в это время могло бы прочитать что находится в буфере сокета... А если для каждого сокета выделяется свой буфер, то можно ли каким-либо образом дублировать пакеты в каждый буфер? Мне нужно unicast. А другое решение искать — это мне нужно для передачи данных по RTP, вернее для RTCP...