Os roteadores NAT reescreveriam a tupla orig-ip: orig-port dos pacotes UDP de saída para nat-ip: nat-port e manteriam uma tabela de relações entre < em> orig-ip: orig-port e nat-ip: nat-port para que os pacotes de resposta UDP cheguem com nat-ip: nat-port como o destino pode ser mapeado de volta para o destino orig-ip: orig-port . Para detalhes sobre como uma implementação NAT pode lidar com as coisas, dê uma olhada em como o rastreamento de conexão é implementado no Linux .
Se a sua implementação não permitir um número de porta de cliente em mudança, simplesmente não seria garantido que funcionasse por trás dos roteadores NAT. Ele pode estar funcionando para um cliente, já que muitas implementações tentariam usar o mesmo número de porta de origem que o pacote original, se disponível, então nat-port seria igual a orig-port para a conexão do primeiro cliente. Mas à medida que essa porta se torna indisponível, as tentativas subseqüentes levam inevitavelmente a uma condição em que nat-port é diferente de orig-port .
Assim, a "chave" básica que você precisaria para diferenciar entre clientes diferentes seria a porta UDP de origem do cliente. Seu aplicativo de bate-papo do servidor precisa gerar pacotes UDP indo para a mesma porta de destino que recebeu um pacote de cliente iniciando a conexão de bate-papo - criando praticamente a mesma situação que você tem com sessões TCP estabelecidas.