* Per-Henrik Lundblom <[EMAIL PROTECTED]> [070608 10:21]: > > > In my case, A's window update is lost by B so that B doesn't know that A > > > now accepts data packets with a size equal or larger than the packet in > > > B's unsent queue. If A's window whould have been 0 bytes, then > > > implementation of TCP persist timer into lwIP whould have solved the > > > problem by letting B probe A for a window update. Now when A's window > > > update is lost, I'm in a deadlock situation. > > > > Hmm, yes, I can see what you're getting at. The only solution here is > > to get B to do zero-window style probes to get a window update from A. > > Normally it would only have to do this when it actually has a zero > > window available to send into, but we need it to probe whenever it has > > seen a window that prevents it sending. Splitting the data might also > > work, but would rather complicate matters, and probably add more code. > > I will look into implementing the persistent timer and using the same > mechanism for sending probes without the remote peer having a zero > window.
Mmm, the probes are basically splitted packets from the unsent queue with a data length of 1 byte. So, the splitting must still be performed =/ I didn't mention it but everything I already have described assumes that the unacked queue is empty. /PH -- Per-Henrik Lundblom epost: [EMAIL PROTECTED] telefon: 0733-20 71 26 hemsida: www.whatever.nu _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
