Em uma questão minha ( "A manipulação arbitrária de Fluxo de conexão TCP causa problemas? ") Eu perguntei se um atraso disposto em uma conexão TCP poderia causar alguns problemas.
Meu proxy HTTP, entre um cliente e um servidor, tem um mecanismo de enfileiramento de prioridade dentro dele: pacotes vindos do cliente ou servidor foram enviados no prio queus, enquanto um thread removedor estava removendo o pacote de mais alto nível das filas do prio. p>
Foi-me dito que
The problem is that TCP has an explicit mechanism to fix reordering problems. This may involve NACK's which force the sender to resend packets.
Your "priority" reordering of bytes in a TCP stream will at best create a lot of resending of data, so your "priority" degrades everything. But it's quite well possible that either side just gives up when the TCP stream is too disrupted.
Eu sei que o TCP é um protocolo confiável com retransmissão de pacotes perdidos e todos os outros recursos, mas não levei em conta que, ao receber do cliente ou servidor e enviar dados em filas, em vez de enviá-los imediatamente para o servidor ou cliente, TCP teria tido algo a objetar sobre este atraso.
Parvo comigo. Desde (eu acho) não há nenhuma maneira de dizer ao servidor para esperar me enviando pacotes uma vez que o pedido é enviado para ele, existe uma maneira de ajustar a tolerância do TCP para julgar um pacote perdido? Ele não está perdido, foi colocado em filas de prio e será enviado ao destino quando o thread de remoção achar que é a sua vez, mas a confiabilidade do TCP pode discordar.