Форум: "Сети";
Текущий архив: 2004.05.30;
Скачать: [xml.tar.bz2];
ВнизКак обработать события когда срабатывает setsockopt() Найти похожие ветки
← →
freak (2004-04-11 03:26) [0]Пишу приложение использующее IP Multicast. Весь смысл в том, что нет клент/сервера в привычном понимании. Проблемма в том, что мне нужно как то отследить, когда пользователь подключился к IP Multicast-группе и когда покинул ее. Теоретически вход и выход из группы реализуется с помощью setsockopt(). С помощю этой функции, маршрутизаторам поддерживающим IP Multicasting, отсылается структура "struct ip_mreq" c опциями IP_ADD_MEMBERSHIP или IP_DROP_MEMBERSHIP. Могу ли я как отследить факт подключения, перехватив как-то это событие;
Это кусок кода из Indy"йского idIPMCastClient:
function TIdIPMCastClient.GetBinding: TIdSocketHandle;
var
i: integer;
Multicast : TMultiCast;
begin
if not Assigned(FCurrentBinding) then
begin
if Bindings.Count < 1 then begin
if DefaultPort > 0 then begin
Bindings.Add;
end else begin
raise EIdMCastNoBindings.Create(RSNoBindingsSpecified);
end;
end;
for i := 0 to Bindings.Count - 1 do begin
Bindings[i].AllocateSocket(Id_SOCK_DGRAM);
Bindings[i].Bind;
Multicast.IMRMultiAddr := GStack.StringToTInAddr(FMulticastGroup);
Multicast.IMRInterface.S_addr := Id_INADDR_ANY;
Bindings[i].SetSockOpt(Id_IPPROTO_IP, Id_IP_ADD_MEMBERSHIP, pchar(@Multicast), SizeOf(Multicast));
end;
FCurrentBinding := Bindings[0];
FListenerThread := TIdIPMCastListenerThread.Create(Self);
FListenerThread.Start;
end;
Result := FCurrentBinding;
end;
← →
Verg © (2004-04-11 10:47) [1]
> С помощю этой функции, маршрутизаторам поддерживающим IP
> Multicasting, отсылается структура "struct ip_mreq" c опциями
> IP_ADD_MEMBERSHIP или IP_DROP_MEMBERSHIP.
Нет, на сколько извеснто мне, при выполнении SetSockOpt(Id_IPPROTO_IP, Id_IP_ADD[DROP]_MEMBERSHIP....
в сеть автоматически не передается никакая информация.
Это указание ядру и собственно сетевому адаптеру принимать датаграммы с указанными мультикастовым адресом(ами) (кстати, у большинства сетевых карт количество их ограничено).
В таких случаях используют протоколы по типу hello в ospf.
Т.е. после подписки на мультикастовый адрес нужно сообщить всем, что "я тут" или hello. При этом этот пакет рассылается с некоторым периодом. При приеме такого пакета, каждый вносит/обновляет этого "соседа" в своем списке. Если от какого-либо соседа долгое время (dead interval) не приходило hello, то он удаляется из списка и отношения смежности (аналог соединения TCP) с ним считаются разорванными.
Для того, чтобы эти, мультикастовые пакеты маршрутизировались (передавались маршрутизаторами за пределы сегмента), договорились использовать поле TTL (для IPV4) в IP заголовке мультикастовой датаграммы, так что датаграмма становится:
0 - локальная в пределах узла (хоста) (по-сути в сеть вообще не передается)
1 - локальная в пределах сети (не маршрутизируется)
<32 - локальный в пределах сайта
<64 - локальная в пределах региона
<128 - локальная в пределах континента
<=255 - глобальная
Понятия сайт, континент, регион определяется администрированием домена маршрутизации.
← →
freak (2004-04-11 17:07) [2]Я запустил IP Monitor (валялся d демках IP*Works v6), потом свое приложение, вот что получил в результате:
При запуске приложения (происходит активация idIPMultiCast):
PROTOCOL :2
SOURCE : 192.168.0.1, port 0
DESTINATION : 224.0.0.22, port 0
FLAGS : 0
ID : 927
Time-To-Live : 4203140
Через некоторое время:
PROTOCOL :17
SOURCE : 192.168.0.1, port 138
DESTINATION : 192.168.0.255, port 138
FLAGS : 0
ID : 928
Time-To-Live : 4203140
Еще через некоторое время:
PROTOCOL :17
SOURCE : 192.168.0.1, port 137
DESTINATION : 192.168.0.255, port 137
FLAGS : 0
ID : 929
Time-To-Live : 4203140
Еще через некоторое время:
PROTOCOL :17
SOURCE : 192.168.0.1, port 138
DESTINATION : 192.168.0.255, port 138
FLAGS : 0
ID : 928
Time-To-Live : 4203140
Выгружаю приложение:
PROTOCOL :2
SOURCE : 192.168.0.1, port 0
DESTINATION : 224.0.0.22, port 0
FLAGS : 0
ID : 934
Time-To-Live : 4203140
Посмотрев исходники Indy, сделал вовод, что
IPMC_IGMP = "224.0.0.22" // IGMP
IPPROTO_IGMP = 2; // group management protocol.
Так что же мне делать? По таймеру отрабатывать стек TCP и смотреть не вышел ли таймаут Hello?
Где мне почитать? Все, что я нашел - это перевод с испанского вот здесь http://www.linuxfocus.org/Russian/January2001/article144.shtml
← →
freak (2004-04-11 22:21) [3]To Verg:
таких случаях используют протоколы по типу hello в ospf.
Т.е. после подписки на мультикастовый адрес нужно сообщить всем, что "я тут" или hello. При этом этот пакет рассылается с некоторым периодом. При приеме такого пакета, каждый вносит/обновляет этого "соседа" в своем списке. Если от какого-либо соседа долгое время (dead interval) не приходило hello, то он удаляется из списка и отношения смежности (аналог соединения TCP) с ним считаются разорванными.
Тогда маршрутизатор должен составлять и поддерживать таблицу интерфейсов, которые имеют одну или более ЭВМ, входящих в мультикастинг-группы. Как к ней получить доступ.
← →
Verg © (2004-04-12 07:02) [4]Так IGMP - это IGMP. Он описан в RFC1112.
← →
Verg © (2004-04-12 07:23) [5]Вот еще почитай, тут более подробно об этом:
http://www.zeiss.net.ru/docs/technol/tcpip/tcp13.htm
← →
freak (2004-04-12 17:36) [6]Огромное спасибо.
← →
Verg © (2004-04-12 18:06) [7]Понятно, да?
Если тебе надо знать всех, кто подписался на группу мультикастинга, то перехват IGMP тебе НЕ поможет, т.к. создан для выяснения всех групп в сегменте, а не всех участников этих групп.
Т.о, твоя задача должна выполнятся в рамках твоего собственного протокола.
← →
freak (2004-04-12 21:43) [8]Понятно. Спасбо за помощь и ссылочку. Думаю сегодня за ночь эту проблемму я решу.
Страницы: 1 вся ветка
Форум: "Сети";
Текущий архив: 2004.05.30;
Скачать: [xml.tar.bz2];
Память: 0.47 MB
Время: 6.081 c