Eu tenho um programa que envia um pacote multicast IPv6 (para ff12::2:0:8afb:382b:c053:85f%en1) a cada 50ms. Eu o coloquei em execução em uma LAN muito simples de um único computador (Mac mini <-wifi-> roteador wifi Linksys <-cat5-> modem DSL <-> Internet). No meu teste não há computadores associados a este grupo multicast (ou seja, ninguém está ouvindo esses pacotes)
Meu problema é que quando este programa está em execução, o desempenho WiFi do Mac cai mais de 50%. Presumivelmente, o problema é que todos esses pacotes multicast estão consumindo grande parte da minha largura de banda WiFi e causando congestionamento... mas não entendo por que os pacotes estão sendo transmitidos. Pelo que entendi, o multicast usa um algoritmo spanning tree para garantir que os pacotes multicast sejam roteados apenas para hosts que estejam realmente interessados em recebê-los. Se isso for verdade, e dado que não há outros computadores na minha LAN associados a esse endereço multicast, meu Mac não deveria perceber isso e não enviar nenhum pacote, a menos que/até que algum outro host se junte ao grupo multicast? Ou a seleção da árvore geradora é implementada apenas no switch, e não pelos próprios hosts?
Responder1
Multicast é uma coisa complicada.Roteadoressão aqueles que arbitram os pacotes multicast, e os switches inteligentes às vezes podem garantir que os pacotes não chegarão aonde não deveriam. No entanto, se não houver roteador entre o multicaster e suas estações clientes (e não há, se estou lendo certo), então o Multicast se comportará exatamente como Broadcasts nessa sub-rede.
Responder2
Para adicionar à resposta de @ sysadmin1138 (este comentário era muito longo para a caixa de comentários)...
Seria bom observar que o 802.11 aumenta o problema aqui de duas maneiras: retransmissão intra-BSS e baixas taxas de multicast.
No 802.11, os quadros 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. Este processo é chamado de "retransmissão intra-BSS" e resolve o que é conhecido como "problema do nó oculto" - onde dois nós sem fio podem estar ao alcance do AP, mas não ao alcance (ocultos) um do outro. Portanto, cada quadro que vem de um cliente sem fio do AP e pode precisar ir para outro cliente sem fio do AP (nota: isso inclui todos os multicasts e transmissões) é transmitido duas vezes pelo mesmo canal. Primeiroparao AP (isso é conhecido como Para o Sistema de Distribuição, ou "ToDS") e novamentedeo AP ("FromDS"), como parte do relé intra-BSS.
O trecho "ToDS" da jornada está na taxa de dados mais alta na qual o cliente pode se comunicar com sucesso com o AP. Portanto, se este for um cliente e AP 3x3 N moderno usando canais de 40 MHz com intervalos de guarda curtos, isso pode ser 450 Mbps.
Infelizmente, para o trecho "FromDS" da jornada, o quadro deve ser enviado a uma taxa de dados baixa o suficiente para que todos os clientes daquele AP os recebam de forma confiável. Isso ocorre porque os multicasts não são confirmados na camada 802.11, pois isso causaria uma tempestade de confirmação em resposta a cada multicast.
Alguns APs permitem definir explicitamente a taxa de multicast. Outros permitem que você defina seu conjunto de taxas “básicas” ou “obrigatórias” e então o AP escolhe a taxa multicast dentre 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 taxa básica predefinido e uma taxa de multicast com base nisso. Muitos APs usam como padrão o modo de compatibilidade total desde as taxas de dados DSSS 802.11-1997 de 1 e 2 Mbps (antes do 802.11b adicionar 5,5 e 11 Mbps). Isso significa que sua taxa multicast pode ser tão baixa quanto 1Mbps.
Então, na pior das hipóteses, seus multicasts poderiam estar devorando 451vezeso tempo de transmissão do canal como um quadro unicast sem fio para fio (ou com fio para sem fio) do mesmo tamanho ocuparia.
Observe também que em alguns projetos, a retransmissão intra-BSS é realizada por microcódigo na NIC 802.11 do AP, portanto, nessas arquiteturas, esses quadros não passam pelo processador host do AP antes de serem retransmitidos. Portanto, mesmo que o AP fosse um switch "inteligente" que pudesse violar o modelo de camadas e fazer espionagem IGMP da 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.
Responder3
O padrão de multicast é o comportamento de transmissão quando não é totalmente suportado pelo roteador local (não pelo switch). Como tal, tende a propagar-se para todos os nós conhecidos dentro de um segmento LAN.
Os roteadores SoHo não são conhecidos por oferecer suporte total ou correto ao MultiCast. Muitos dependem de roteadores upstream e esperam apenas clientes no nível da LAN. Você pode tentar ajustar as configurações do roteador, mas se o seu grupo multicast não tiver assinantes, por que não desligá-lo na fonte?