Маршрутизация широковещательного UDP

[sinsin]

Доброго времени суток.
Есть один вопрос по функцинированию стека TCP/IP в Windows: я посылаю широковешательный UDP пакет на некоторый порт, например так:

Код:

sockaddr_in RecvAddr;
RecvAddr.sin_family = AF_INET;
RecvAddr.sin_port = htons(RBC_UDP_RECEIVER_PORT);
RecvAddr.sin_addr.s_addr = INADDR_BROADCAST;

int iResult = sendto(SendSock,&CicleBuf[ReadIndex*RBC_ONE_PACCKET_LEN], RBC_ONE_PACCKET_LEN, 0, (SOCKADDR *) & RecvAddr, sizeof (RecvAddr));
if (iResult == SOCKET_ERROR) {
	wprintf(L"sendto failed with error: %d\n", WSAGetLastError());
}

На той же машине, с которой он отправлен я его принимаю:

Код:

sockaddr_in ServAddr;
ServAddr.sin_family = AF_INET;
ServAddr.sin_port = htons(RBC_UDP_RECEIVER_PORT);
ServAddr.sin_addr.s_addr = INADDR_ANY;

sockaddr RcvAddr;
ZeroMemory(&RcvAddr, sizeof(sockaddr_in));

bind( UDPReceiverSock, (sockaddr*)&ServAddr, sizeof(ServAddr));

int BytesReceived = recvfrom(UDPReceiverSock,TmpBuf, RBC_ONE_PACCKET_LEN, 0, &RcvAddr, &ir);

А какой был маршрут у этого пакета с момента его отправления:
через сетевую карту или через Loopback?

[Finch]

По идее говоря через Loopback, Посылаеш широковешательный, следовательно и через адрес 127.0.0.1 Насколько я знаю, раутеры должны резать этот адрес.

[sinsin]

Ясно. А можно ли как-нибудь запретить Loopback?

[Dimka]

sinsin, ты бы лучше сказал, что ты хочешь получить в конечном результате. Заслать "в провод" пакет так, чтобы он "из провода" вернулся у тебя никогда не получится.

[Finch]

Можеш в принципе на Файраоле написать правило, чтобы, он глушил UDP пакеты идушие по 127.0.0.1 адресу и твоему порту. Совсем закрывать интрефейс чревато. Слишком многое на нем работает.

[RXL]

sinsin, ты бы лучше сказал, что ты хочешь получить в конечном результате. Заслать "в провод" пакет так, чтобы он "из провода" вернулся у тебя никогда не получится.

Не знаю как в вашей винде, классические BSD-сокеты не запрещают получать собственное широковещательное отправление. Более того, можно регулировать его получение.

[Dimka]

RXL, а кто его вернёт на 2-м уровне OSI?

[RXL]

Дим, при чем тут 2-й уровень? Вопрос в логике выбора интерфейса для отправки. Если бы это был multicast, то в подобной ситуации ушел бы через все интерфейсы, но broadcast может уйти только с одного интерфейса. Без выполнения bind или connect для сокета, выбор интерфейса остается за системой. Быстрее всего выбран будет первый попавшийся интерфейс в списке (т.к. адрес не спицифичен к конкретному интерфейсу). Отсюда: делать bind. Но это я описываю классические сокеты — винда, ведь, уникум...

[Dimka]

RXL, при том, что "в провод" не уйдёт. Перетасуется на 3-м уровне. Он потому и хочет lo запретить, чтобы пакет внутри машины не ходил, только не добьётся желаемого. Поэтому вопрос о маршруте, которым ходил пойманный собственный бродкаст, смысла не имеет - маршрута как такового для этого пакета вообще нет.

[RXL]

Цитирую классика:

Адрес 255.255.255.255 предназначен с использованием в качестве адреса получателя во время процесса начальной загрузки такими приложениями, как TFTP и BOOTP, которым еще не известен IP-адрес узла.

Возникает вопрос: что делает узел, когда приложение посылает дейтаграмму UDP на адрес 255.255.255.255? Большинство узлов допускают это (если процесс установил параметр сокета SO_BROADCAST) и преобразуют адрес получателя в широковещательный адрес исходящего интерфейса, направленный в подсеть. ...

Может появиться другой вопрос: что делает узел с несколькими сетевыми интерфейсами, когда приложение посылает дейтаграмму UDP на адрес 255.255.255.255? Некоторые системы посылают одно широковещательное сообщение с основного интерфейса (с интерфейса, который был сконфигурирован первым) с IP-адресом получателя, равным широковещательному адресу подсети этого интерфейса. Другие системы посылают по одной копии дейтаграммы с каждого интерфейса, поддерживающего широковещательную передачу. ...

Короче, систем специфик — курим MSDN.

Совет:
1. Привязывать (bind) сокет к определенному широковещательному адресу, характерному непосредственно доступной сети.
2. Если надо послать широковещательный пакет в несколько непосредственно доступных сетей, создавать по сокету для каждой и посылать через каждый копию пакета.

[Dale]

Не знаю как в вашей винде, классические BSD-сокеты не запрещают получать собственное широковещательное отправление.

В нашей винде, разумеется, все точно так же.

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

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

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

[RXL]

Dale, значит ли это, что буфер UDP в винде резиновый?

Добавлено через 2 минуты и 4 секунды:

В нашей винде, разумеется, все точно так же.

Я верю в MS. Winsock изначально было с извратом.

[Dale]

Может, есть возможность как-то регулировать его аппетит, я не искал такое средство. В "моем" случае забивались все 3 гигабайта виртуальной памяти процесса (приложение 32-разрядное), после чего следовал крах.

Решил проблему простейшим способом - заставил программу делать пустое чтение собственного сокета, после чего дальше уже копать не было интереса.

[RXL]

Совет:
1. Привязывать (bind) сокет к определенному широковещательному адресу, характерному непосредственно доступной сети.
2. Если надо послать широковещательный пакет в несколько непосредственно доступных сетей, создавать по сокету для каждой и посылать через каждый копию пакета.

Поправлюсь: bind не обязателен, но в sendto надо явно указывать адрес назначения и, для посылки в несколько сетей, выполнять соотв. число sendto с соотв. этим сетям адресом назнанчения.

Добавлено через 2 минуты и 37 секунд:
Dale, был ли в приложении открыт UDP сокет, связанный с данным портом? В противном случае пакет должен игнорироваться системой.

[Dale]

Dale, был ли в приложении открыт UDP сокет, связанный с данным портом? В противном случае пакет должен игнорироваться системой.

Конечно, был. Иначе и самой проблемы не было бы.

Там приложение в принципе дуплексное (учебный класс): сервер не только транслирует контент, но и принимает обратную связь от ученических мест. Только разработчики не учли, что собственная трансляция туда тоже попадет.