Kacheong Poon writes: > Roch - PAE wrote: > > > > It is worth trying. But I suspect that the delay may > > > need to be dynamic and adaptive. For example, if the app is > > > doing a simple request/response type of transaction, the > > > above will introduce the minimum delay for every request and > > > response. > > > > > > > Apps that uses multiple small writes for a requests then > > wait for a response benefit greatly from setting > > TCP_NODELAY as this would bypass the block in both networked and > > fused case. > > > Yes. But I was not suggesting this case. I meant just a simple > request/response protocol. The request and response can be a > single write. Nagle algorithm won't matter in the networked > case so there is no need to set TCP_NODELAY. But the above delay > on read will show up in loopback case. I was trying to point > out a possible side effect on some apps if the delay is not > adaptive.
Ok. sorry. I think we can be much like Nagle. The delay can be inserted between 2 successive outgoing writes. The first write wakes up the peer (and starts a timer). A read, if issued, cancels the timer. But a second write shortly after a first one will not cause a wakeup of the peer; data is buffered. All like Nagle. Only difference is that instead of waiting for an ACK, we wait for a fix timer. > > -- > > K. Poon. > [EMAIL PROTECTED] > > _______________________________________________ > networking-discuss mailing list > [email protected] _______________________________________________ networking-discuss mailing list [email protected]
