Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
| |
У меня не используется RRAS. Используется опция «Enable IP forwarding» + соотв. команды route 05.08.04 14:17 Число просмотров: 1671
Автор: HandleX <Александр М.> Статус: The Elderman
|
|
|
|
<programming>
|
Вопрос про сокеты и UDP Multicast. 05.08.04 12:12
Автор: HandleX <Александр М.> Статус: The Elderman
Отредактировано 05.08.04 12:14 Количество правок: 1
|
Итак, ситуация... Есть программа (VyPress Chat), используемая в конторе по своему прямому назначению. Она не использует для своей работы выделенного сервера сообщений, а использует UDP Multicast. Как известно, виндовозный роутер не может форвардить мультикаст-траффик на другие интерфейсы. А это надо, дабы чат работал в обоих офисах. Итак, пишу программу-повторитель, которая слушает UDP, с приходом нужного пакета инкапсулирует его и передаёт по TCP в другой такой-же повторитель в другом офисе, тот его принимает и делает Multicast. Вопрос: после мультикаста свой же пакет попадёт в "слушающую" часть повторителя. Как этого избежать? Есть ли "грамотные" методы, или выставлять глобальный флаг типа DropNextPacket ? А как узнать, тот ли это пакет, сеть ведь штука непредсказуемая... В общем, надо как-то помечать "свои" пакеты.
Заранее всем большое спасибо за советы.
|
|
Re: Вопрос про сокеты и UDP Multicast. 05.08.04 17:27
Автор: leo <Леонид Юрьев> Статус: Elderman
|
Во-первых это всё неправильно, и конфликтует с RFC.
Ну а если хочеться сделать можно так:
вариант 1 - при передаче UDP от повторителя использовать source_address = 127.0.0.1 или просто левый адрес, соответственно в слушающей части игнорировать пакеты такие пакеты;
вариант 2 - использовать другой UDP-source-port...;
вариант 3 - при передаче UDP от повторителя делать broadcast в пределах сети, но увидят эти пакеты клиенты или нет зависит от chat-клиента;
|
| |
Как это конфликтует? ;-) 06.08.04 10:40
Автор: HandleX <Александр М.> Статус: The Elderman
Отредактировано 06.08.04 10:43 Количество правок: 1
|
> Во-первых это всё неправильно, и конфликтует с RFC.
Мне, честно говоря, вообще на IP и его RFC плевать, с самого начала надо было искать решение типа Ethernet-репитера. Гемор с разными подсетями раздражает давно и сильно.
А раз я не нашёл такого решения под NT4 (а надо было именно под него), то теперь увы, приходится внедрять решение через то самое место, через которое у нас обычно всё внедряется ;-)
PS: с каким RFC что у меня конфликтует?
|
| | |
Если мне не изменяет память, то изначально для multicast в... 13.08.04 19:35
Автор: leo <Леонид Юрьев> Статус: Elderman
|
Если мне не изменяет память, то изначально для multicast в RFC (конечно не помню в каком) предусмотрен только как-бы "half-duplex" routing. Т.е. нельзя роутить одинаковый multicast из одной сети в другую и обратно, а только в одну сторону. Или другими словами, multicast-маршрут имеет явно заданное одностроннее направление.
С другой стороны уже есть RFC2715 (http://www.ietf.org/rfc/rfc2715.txt) и может быть есть софт который это делает...
|
|
дык recvfrom возвращает адрес отправителя пакета... 05.08.04 13:31
Автор: Killer{R} <Dmitry> Статус: Elderman
|
|
|
| |
Прикол в том, что роутер «рабочая лошадка», и на нём тоже работает человек, и, соответственно, будет запущен VyPress Chat, и адрес отправителя пакетов будет тот же, что и у повторителя. 05.08.04 14:19
Автор: HandleX <Александр М.> Статус: The Elderman
|
|
|
| | |
А UDP номер порта отправителя уже отменили? Он не может быть... 05.08.04 15:20
Автор: Killer{R} <Dmitry> Статус: Elderman
|
|
А UDP номер порта отправителя уже отменили? Он не может быть одинаковым у вайпресса и повторителя.
|
| | | |
Это TCP не может... А UDP — может! 05.08.04 16:26
Автор: HandleX <Александр М.> Статус: The Elderman
|
|
|
| | | | |
Ну да.. Если захочет Ж) 05.08.04 16:46
Автор: Killer{R} <Dmitry> Статус: Elderman
|
Тода наверно придется сделать с хэшами. А для надежности - очередь на 100 пакетов, отсортированная по хэшам для быстрого поиска.
Еще вариант - IPPROTO_RAW и самому собирать и слать пакеты в интерфейс...
|
| | | | | |
А ipproto_raw поддерживается на nt4? 05.08.04 16:54
Автор: HandleX <Александр М.> Статус: The Elderman
|
|
|
| | | | | | |
Не-а.. Тока 2000 и выше и тока под админом 05.08.04 17:55
Автор: Killer{R} <Dmitry> Статус: Elderman
|
Если продолжить заниматься мозгое... мозговым штурмом то можно еще сделать API hooking для твоего чата, который перехватывая socket, bind, send, recv или что там он юзает перенаправлял бы их серверу по TCP, который в свою очередь рассылал бы всем остальным клиентам, а они бы думали что это UDP броадкаст.. Изврат конечно зато может получится довольно универсальная штука. Особенно если делать это не через API hooking а через LSP... Хотя очередь последних пакетов намного проще Ж)
ЗЫ заюзали бы серверный TCP чат. Тот же ирк...
|
|
Я чего то не понял 05.08.04 12:41
Автор: amirul <Serge> Статус: The Elderman
|
|
Если пакет пришел с одного интерфейса - броадкастить его в другой. И наоборот. Каким образом пакет может повторяться?
|
| |
Объясняю. 05.08.04 14:39
Автор: HandleX <Александр М.> Статус: The Elderman
|
> Если пакет пришел с одного интерфейса - броадкастить его в
> другой. И наоборот. Каким образом пакет может повторяться?
Повторитель содержит несколько частей. Первая часть по TCP связывается с другим таким же повторителем, дабы передавать инкапсулированные UDP-пакеты другому, но который в другой подсети. Т.е. по одному интерфейсу ходят только TCP-пакеты, и с ними проблем нет.
Нас интересует приёмо-передающая часть UDP, которая на другом интерфейсе. Приёмная часть слушает UDP на порту. Итак, пришёл пакет. Передаёт его по TCP другому повторителю. Тот делает ему Multicast в "родную" подсеть. Но там ведь и слушающая часть! И она примет этот пакет.
Повторяю вопрос: как метить "свои" пакеты? Может, CRC данным считать, и, если совпадает с только что переданным, то можно дропать его с большой вероятностью?
|
| | |
CRC плохо - большая вероятность коллизии. Лучше хранить md5... 05.08.04 17:40
Автор: NKritsky <Nickolay A. Kritsky> Статус: Elderman
|
|
CRC плохо - большая вероятность коллизии. Лучше хранить md5 хэши. Причем последних 10 пакетов. Этого должно быть достаточно.
|
| | | |
Да ну их совсем, эти хэши... Для 10 пакетов я лучше просто данные сохраню, быстрее будет. 06.08.04 12:10
Автор: HandleX <Александр М.> Статус: The Elderman
|
|
|
|
Win может роутить multicast 05.08.04 12:39
Автор: leo <Леонид Юрьев> Статус: Elderman
|
> роутер не может форвардить мультикаст-траффик на другие
Может, смотри доки по RRAS.
|
| |
У меня не используется RRAS. Используется опция «Enable IP forwarding» + соотв. команды route 05.08.04 14:17
Автор: HandleX <Александр М.> Статус: The Elderman
|
|
|
| | |
А разве Multicast UPD пакет не содержит адрес отправителя? 13.08.04 18:58
Автор: DiVider Статус: Незарегистрированный пользователь
|
|
|
|
|
подробно о проекте
Анализ криптографических сетевых...
