Rainer Toebbicke wrote:
In the above scenario the sender actually knows a lot upon ack - how fast the receiver is digesting packets and what holes he's got. What would you conclude if you received an ACK looking like----++++++++++++++++----++++--------+++++----++++++++++++ ?
Two possibilities jump to mind: 1. congestion2. the receiver is performing a very cpu expensive operation (decryption) which prevents it from reading addition packets
from the socket and the socket buffer has filled resulting in packet loss. I was seeing that pattern very frequently in the Windows AFS client until I turned on Rx Hot Threads.
Common practice suggests keeping sender & receive at the same pace is best, hence reducing the window would be the answer. But the price is high as the pace can change and the sender would know only late because of latency! And since memory is cheap, perhaps always filling big windows with lots (200? 500?) of packets assuming efficient queuing and dealing with drops is better, even under congestion?
Improving the ability of the receiver to get packets out of the socketbuffer at a faster rate and therefore being able to truly manage the window size within Rx is crucial. I believe that there is still too
much overhead in the rx_Listener being performed between recvmsg() calls.
smime.p7s
Description: S/MIME Cryptographic Signature
