информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Где водятся OGRыSpanning Tree Protocol: недокументированное применениеСетевые кракеры и правда о деле Левина
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Очередное исследование 19 миллиардов... 
 Оптимизация ввода-вывода как инструмент... 
 Зловреды выбирают Lisp и Delphi 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / networking
Имя Пароль
если вы видите этот текст, отключите в настройках форума использование JavaScript
ФОРУМ
все доски
FAQ
IRC
новые сообщения
site updates
guestbook
beginners
sysadmin
programming
operating systems
theory
web building
software
hardware
networking
law
hacking
gadgets
job
dnet
humor
miscellaneous
scrap
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
Думаю да. 18.05.04 17:41  Число просмотров: 1724
Автор: NKritsky <Nickolay A. Kritsky> Статус: Elderman
<"чистая" ссылка>
> Логика транспортировки фреймов Ethernet у non-managed
> свичей для мультикаст пакетов точно такая же, как и для
> броадкаст? Иными словами, JoinHostGroup имеет действие
> только на локальный IP service interface (в терминах RFC)?

в смысле, что non-managed свитчи и managed свитчи с дефолтными настройками чихать хотели на JoinHostGroup. Видят что первые три октета адреса - мультикастные, и хреначат во все порты. Но клястся не буду :)
<networking>
Вопрос: IP мультикаст в сетях Ethernet основан на Ethernet-броадкасте? В чём же тогда отличие multicast от broadcast? ;-) 18.05.04 16:05  
Автор: HandleX <Александр М.> Статус: The Elderman
<"чистая" ссылка>
ну приехали 18.05.04 16:10  
Автор: ZloyShaman <ZloyShaman> Статус: Elderman
Отредактировано 18.05.04 16:11  Количество правок: 1
<"чистая" ссылка>
Мультикаст работает на уровне IP. Наверное.
Sorry, объясню поточнее... 18.05.04 16:16  
Автор: HandleX <Александр М.> Статус: The Elderman
<"чистая" ссылка>
Итак, имеем прогу, слушающую на порту xxxx

Посылаю IP пакет на 255.255.255.255 порт xxxx - прога пакет получает.
Посылаю пакет на 227.0.0.2 порт xxxx - прога всё равно получает пакет ;-)

В чём разница?
ответ на сайте www.ietf.org 18.05.04 16:37  
Автор: NKritsky <Nickolay A. Kritsky> Статус: Elderman
<"чистая" ссылка>
> Итак, имеем прогу, слушающую на порту xxxx
>
> Посылаю IP пакет на 255.255.255.255 порт xxxx - прога пакет
> получает.
> Посылаю пакет на 227.0.0.2 порт xxxx - прога всё равно
> получает пакет ;-)
>
> В чём разница?

Разницу легко установить при помощи сниффера:
broadcast packet имеет ethernet destination addr:
ff:ff:ff:ff:ff:ff
multicast packet имеет ehernet destination addr:
01:005e:xx:xx:xx

Что достаточно подробно расписано в RFC1112 (Multicast).
Великая сила RTFM... Прочитал RFC, успокоился ;-) Всем спасибо за разъяснение! Но остался маленький вопрос... 18.05.04 17:26  
Автор: HandleX <Александр М.> Статус: The Elderman
Отредактировано 18.05.04 17:35  Количество правок: 1
<"чистая" ссылка>
Логика транспортировки фреймов Ethernet у non-managed свичей для мультикаст пакетов точно такая же, как и для броадкаст? Иными словами, JoinHostGroup имеет действие только на локальный IP service interface (в терминах RFC)?
Думаю да. 18.05.04 17:41  
Автор: NKritsky <Nickolay A. Kritsky> Статус: Elderman
<"чистая" ссылка>
> Логика транспортировки фреймов Ethernet у non-managed
> свичей для мультикаст пакетов точно такая же, как и для
> броадкаст? Иными словами, JoinHostGroup имеет действие
> только на локальный IP service interface (в терминах RFC)?

в смысле, что non-managed свитчи и managed свитчи с дефолтными настройками чихать хотели на JoinHostGroup. Видят что первые три октета адреса - мультикастные, и хреначат во все порты. Но клястся не буду :)
1




Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2025 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach