Почему мои многоадресные пакеты слушателя меньше влияют на производительность Wi-Fi?

Кажется, что компиляция с SSL стоила бы усилия.

С другой стороны, Вы могли открыть SSL "туннель прокси" от клиентской машины до поля сервера Linux (использующий Шпаклевку), и затем Ваш клиент будет эффективно зашифрованный. Просто идея, если Вы наклоняетесь, получает SSL в Ваш MySQL.

2
задан 9 August 2010 в 23:06
3 ответа

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

2
ответ дан 3 December 2019 в 08:44

Добавить к ответу @sysadmin1138 (этот комментарий был слишком длинным для поля комментариев)...

Было бы хорошо отметить, что 802.11 добавляет к боли здесь двумя способами: реле внутри-BSS и низко многоадресные уровни.

На 802,11, беспроводная связь к кадрам данных беспроводной сети на том же AP должна ретранслироваться с помощью беспроводных технологий AP в случае, если исходный отправитель не находится в радио-диапазоне предполагаемого получателя. Этот процесс называют "реле внутри-BSS" и решает то, что известно как "скрытая проблема узла" - где два беспроводных узла могут оба быть в диапазоне AP, но не в диапазоне (скрыты от) друг друга. Так каждый кадр, который прибывает из одного беспроводного клиента AP и, возможно, должен перейти к другому беспроводному клиенту AP (примечание: это включает все многоадресные сообщения, и широковещательные сообщения) передается через тот же канал дважды. Сначала к AP (это известно Относительно Системы распределения или "ToDS"), и с другой стороны от AP ("FromDS"), как часть реле внутри-BSS.

Участок "ToDS" поездки на самой высокой скорости передачи данных, на которой клиент может успешно общаться с AP. Таким образом, если это - современный клиент на 3x3 Н и AP с помощью каналов на 40 МГц с короткими защитными интервалами, это может быть 450 Мбит/с.

К сожалению, для участка "FromDS" поездки, кадр должен быть передан на скорости передачи данных достаточно низко для всех клиентов что AP для получения их надежно. Поэтому многоадресными сообщениями не является Acked на 802,11 слоях, потому что он вызвал бы шторм Ack в ответ на каждую многоадресную передачу.

Некоторый APS позволил Вам установить многоадресный уровень явно. Другие позволяют Вам определить свой "основной" или "необходимый" набор уровня, и затем AP выбирает многоадресный уровень из базовых скоростей. Все еще другие просто позволяют Вам установить свой b/g/n (или a/n) режим эмуляции, и установить предопределенную базовую скорость и многоадресно передать уровень на основе этого. Много значений по умолчанию APS к полному режиму эмуляции полностью назад к 802.11-1997 скоростям передачи данных DSSS 1 и 2 Мбит/с (прежде чем 802.11b добавил 5.5 и 11 Мбит/с). Это означает, что Ваш многоадресный уровень мог быть всего 1 Мбит/с.

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

Обратите внимание также, что в некоторых проектах, реле внутри-BSS выполняется микрокодом в 802,11 NIC AP, таким образом, на той архитектуре, эти кадры не проходят через главный процессор AP, прежде чем они будут переданы. Таким образом, даже если бы AP было "умным" переключателем, который мог бы нарушить модель разделения на уровни и сделать уровень 3 IGMP, шпионящий для сокращения дерева многоадресной передачи, то это не получило бы шанс сделать это, прежде чем плата радиоблока уже сделала реле внутри-BSS на кадре.

8
ответ дан 3 December 2019 в 08:44
  • 1
    +1. Очень информативный. Спасибо за образование. :) –  joeqwerty 10 August 2010 в 06:00

Многоадресные значения по умолчанию для широковещательной передачи поведения, если не полностью поддерживаемого локальным маршрутизатором (не переключаются). Как таковой это имеет тенденцию распространять ко всем известным узлам в сегменте LAN.

Маршрутизаторы Сохо не известны за поддержку MultiCast полностью или правильно. Многие зависят от восходящих маршрутизаторов и ожидают только клиенты на уровне LAN. Можно ли попытаться корректировать установки маршрутизатора, но если группа многоадресной передачи не имеет никаких подписчиков, почему бы не выключить его в источнике?

0
ответ дан 3 December 2019 в 08:44
  • 1
    Это - однонаправленный протокол данных, таким образом, источник многоадресной передачи не знает, существуют ли подписчики или нет. (Я рассчитывал на слой многоадресной маршрутизации для обработки той проблемы... Я предполагаю, что ожидал слишком много :P) –  Jeremy Friesner 9 August 2010 в 21:24

Теги

Похожие вопросы