TCP/UDP e MTU ethernet Fragmentação

Question

Eu li vários sites e tutoriais on-line, mas eu ainda estou confuso.Se a mensagem for maior que o MTU de IP e, em seguida, send() retorna o byte enviado.O que acontece para o resto da mensagem?Sou eu a chamar send() novamente e tentar enviar resto da mensagem?Ou é algo que camada IP deve tomar cuidado automaticamente?

Answer 1

Se você estiver usando o TCP, em seguida, a interface apresentada é que, de um fluxo de bytes.Você não necessita preocupar-se sobre como a sequência de bytes, fica, desde uma extremidade da conexão para o outro.Você pode ignorar a camada IP da MTU.Na verdade, você pode ignorar a camada IP inteiramente.

Quando você chamar send() a pilha TCP em sua máquina irá lidar com todos os detalhes necessários para o fluxo de bytes que você está empurrando para o envio de chamadas a aparecer a partir de recv() chama-se na outra extremidade da conexão.

A única coisa a lembrar é que com o TCP, você está lidando com um fluxo e que significa que um send() pode resultar em dados que chegam em vários recv() chamadas e várias send() as chamadas podem resultar em dados que chegam em uma única recv() chamada.Você não tem controle sobre isso.Você está lidando com um fluxo de bytes e cada chamada para recv() pode retornar qualquer número de bytes de 1 para o número atualmente em circulação (permitindo a adequada buffers passado para o recv() chamada).

Desde os comentadores pediu para ele ;)

Na maioria das pilhas de TCP send() é mais provável que não enviar tudo porque a pilha TCP do buffers estiverem completos e (provavelmente) a janela TCP também é cheia de controle de fluxo e está em operação, o que significa que a pilha não pode enviar mais dados até que a extremidade remota ACKs alguns dados e ele não é preparado para a memória intermédia mais em seu nome.Eu não encontrei uma pilha TCP que vai recusar um send() devido a MTU considerações sozinho, mas eu acho que alguns reduzido sistemas embarcados podem se comportar dessa maneira...

De qualquer maneira, se send() retorna menor do que o número de bytes que você forneceu, em seguida, você deve reenviar os dados restantes em algum ponto.Muitas vezes send() irá bloquear e aguarde até que ele possa enviar todos os dados, e se você tiver definido o socket para não modo de bloqueio, em seguida, você provavelmente NÃO quer novamente imediatamente a enviar se não conseguir enviar tudo como você provavelmente vai acabar em um loop forte...

Ele provavelmente seria útil para você ser mais específico sobre o sistema operacional que você está usando.

Answer 2

Se o pacote for muito grande para transitar a rede, uma dica de fragmentação do ICMP será enviada sinalizando o remetente para reduzir o tamanho do pacote e tentar novamente.

Se você usar o TCP, esses são todos os detalhes que você deve esperar que a camada de rede cuide de você. O que as pilhas IP modernas realmente fazem nos bastidores para descobrir o MTU mais baixo ao longo do caminho parece ter se tornado uma arte negra.

WRT UDP Você ainda pode esperar que a pilha se fragmentasse para você, mas praticamente, dado o caso de uso para o UDP, não é o ideal. Dependendo do seu aplicativo, é provável que você verá melhor desempenho, entendendo explicitamente o caminho da MTU.

... Na pergunta send (), algumas pilhas se comportam de maneira diferente, mas o tratamento que seu código deve ser o mesmo. Digamos que você tenha 100 bytes para enviar ... send () retorna 10 bytes enviados. Você precisa continuar ligando para enviar com os 90 bytes restantes até que tudo empurrou o fio para enviar a mensagem inteira.

Usando soquetes de bloqueio na plataforma do Windows send () retornará geralmente depois que tudo for enviado. Em outras plataformas. Linux et al, você precisará continuar enviando com mais frequência para pressionar os dados.