In a question of mine (Does arbitrary manipulation of TCP connection flow cause problems?) I asked whether a willing delay in a TCP connection could cause some troubles.My HTTP proxy, between a client and a server, has a priority queueing mechanism within it: packets coming from client or server were pushed in prio queus, while a remover thread was removing the highest prio packet from prio queues.I was told that 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.I know that TCP is a reliable protocol with retransmission of lost packets and all other features, but I did not take in account that, when receiving from client or server and pushing data in queues instead of sending them right away to server or client, TCP would have had something to object about this delay.Silly me. Since (I guess) there is no way to tell the server to wait sending me packets once the request is sent to it, is there a way to adjust the tolerance of TCP to judge a packet lost? It is not lost, it has been pushed in prio queues and will be sent to destination once the remover thread will think it is its turn, but the reliability of TCP may disagree.
Is there a way to tune TCP about packet loss and retransmission?
tcp;c;socket