Por que meus pacotes multicast sem ouvinte estão afetando o desempenho do Wifi?

2

Eu tenho um programa que envia um pacote multicast IPv6 (para ff12 :: 2: 0: 8afb: 382b: c053: 85f% en1) a cada 50ms. Eu tenho isso em execução em uma LAN de computador simples muito simples (Mac mini < -wifi- & Links; roteador wifi Linksys < -cat5- > modem DSL < - > Internet). No meu teste não há computadores ligados a este grupo multicast (ou seja, ninguém está ouvindo esses pacotes)

Meu problema é que, quando esse programa está em execução, o desempenho do WiFi do Mac cai mais de 50%. Presumivelmente, o problema é que todos esses pacotes multicast estão consumindo muito da minha banda larga WiFi e causando congestionamento ... mas eu não entendo porque os pacotes estão sendo transmitidos. No meu entender, o multicast usa um algoritmo de spanning tree para garantir que os pacotes multicast sejam roteados apenas para hosts realmente interessados em recebê-los. Se isso for verdade, e dado que não há outros computadores em minha LAN unidos a este endereço multicast, o meu Mac não deve perceber isso e não enviar realmente nenhum pacote a menos que / até que algum outro host se junte ao grupo multicast? Ou a seleção da árvore de abrangência é implementada apenas no comutador, e não pelos próprios hosts?

    
por Jeremy Friesner 09.08.2010 / 19:09

3 respostas

2

O multicast é uma coisa complicada. Os Roteadores são os que arbitram os pacotes de multicast, e os switches inteligentes às vezes podem garantir que os pacotes não cheguem onde eles não deveriam ir. No entanto, se não houver um roteador entre o multicaster e as estações do seu cliente (e não houver, se eu estiver lendo isso corretamente), o Multicast se comportará exatamente como os Broadcasts nessa sub-rede.

    
por 09.08.2010 / 19:20
8

Para adicionar a resposta do @ sysadmin1138 (este comentário foi muito longo para a caixa de comentários) ...

Seria bom notar que o 802.11 aumenta a dor aqui de duas maneiras: relé intra-BSS e baixas taxas de multicast.

No 802.11, os quadros sem fio para sem fio no mesmo AP devem ser retransmitidos sem fio pelo AP, caso o remetente original não esteja no alcance de rádio do destinatário pretendido. Esse processo é chamado de "relé intra-BSS" e resolve o que é conhecido como "problema do nó oculto" - em que dois nós sem fio podem estar no alcance do AP, mas não dentro do alcance (oculto) do outro. Assim, cada quadro que vem de um cliente sem fio do ponto de acesso e pode precisar ir para outro cliente sem fio do ponto de acesso (nota: isso inclui todos os multicasts e transmissões) é transmitido pelo mesmo canal duas vezes. Primeiro para o AP (isto é conhecido como Para o Sistema de Distribuição, ou "ToDS") e então novamente do o AP ("FromDS"), como parte de intra- Relé BSS.

A etapa "ToDS" da jornada está na maior taxa de dados na qual o cliente pode se comunicar com êxito com o AP. Então, se este for um cliente N moderno de 3x3 e AP usando canais de 40MHz com intervalos de guarda curtos, isso pode ser 450mbps.

Infelizmente, para a etapa "FromDS" da jornada, o quadro deve ser enviado a uma taxa de dados baixa o suficiente para que todos os clientes desse AP recebam-nos de forma confiável. Isso porque multicasts não são Acked na camada 802.11, porque causaria uma tempestade Ack em resposta a cada multicast.

Alguns APs permitem definir a taxa de multicast explicitamente. Outros permitem que você defina o seu conjunto de taxas "básico" ou "obrigatório" e, em seguida, o AP escolhe a taxa de multicast entre as taxas básicas. Outros ainda permitem que você defina seu modo de compatibilidade b / g / n (ou a / n) e tenha um conjunto de taxas básicas e uma taxa de multicast pré-definidos com base nisso. Muitos APs usam como padrão o modo de compatibilidade total até as taxas de dados 802.11-1997 DSSS de 1 e 2 mbps (antes que 802.11b adicionasse 5.5 e 11mbps). Isso significa que sua taxa de multicast pode ser tão baixa quanto 1mbps.

Assim, na pior das hipóteses, seus multicasts podem estar devorando 451 vezes o tempo de transmissão do canal como um quadro unicast sem fio com fio (ou com fio para sem fio) do mesmo tamanho ocuparia.

Note também que, em alguns projetos, o relé intra-BSS é realizado por microcódigo na NIC 802.11 do AP, portanto, nessas estruturas, esses quadros não passam pelo processador host do AP antes de serem retransmitidos. Assim, mesmo que o AP fosse um switch "inteligente" que pudesse violar o modelo de camadas e fazer o snooping IGMP na camada 3 para podar a árvore multicast, ele não teria a chance de fazer isso antes que a placa de rádio já tivesse feito intra-BSS retransmitir no quadro.

    
por 10.08.2010 / 04:55
0

O Multicast padrão é para transmitir o comportamento quando não é totalmente suportado pelo roteador local (não pelo switch). Como tal, tende a se propagar para todos os nós conhecidos dentro de um segmento de rede local.

Os roteadores SoHo não são bem conhecidos por suportar o MultiCast total ou corretamente. Muitos dependem de roteadores upstream e esperam apenas clientes no nível da LAN. Você pode tentar ajustar as configurações do seu roteador, mas se o seu grupo multicast não tiver assinantes, por que não desligá-lo na fonte?

    
por 09.08.2010 / 19:19