On Wednesday 02 Mar 2011 16:54:43 Matthew Toseland wrote: > We have two conflicting goals: > > 1. We want quick responses, especially for realtime requests, but in general, > at the layer of requests, inserts, sending messages etc. > > 2. We want TCP-like behaviour that is tolerant of packet loss, and works with > firewalls. > > It turns out that in some common cases these are mutually incompatible, > pointing in opposite directions. > > There are a fair number of places where we use a 10 second timeout. For > instance, when we send an Accepted to a CHK inserter, it should reply within > 10 seconds with a DataInsert. > > The problem is: > - The RFCs for TCP specify that retransmit timeouts start at ~ 2 seconds and > increase up to ~ 120 seconds. Note that before we implemented this (RFC 2988) > we had massive amounts of retransmission. > - We send keepalives every 7-14 seconds (was 14-28 seconds) and timeout a > connection if we receive no packets in 35 seconds (was 60 seconds). > > Network congestion and temporary glitches can cause severe latency. Severe > latency is incompatible with quick responses. For instance, my connection > seems to get 15 second pauses during which no packets are received from a > given peer; this could be a problem with my ISP or my router, but if I get it > it's likely a lot of other people get it too. We need to deal with this > properly, but how? > > Most places we now implement a two stage timeout. If we get a response within > a short period then we proceed; if we don't, we wait (off-thread, while the > main thread reroutes) for a longer period. If we still don't get a response > something is seriously wrong so we disconnect. Lately problems seem to mostly > come up in the few places that don't do this so arguably the default strategy > is to implement two stage timeout in those places. But it's a bit of a mess, > maybe there is a better solution? > > Another option would be to have a much shorter connection timeout (which > would require we send keepalives much more often), or a much longer timeout > in many of these cases. > > Thoughts? > Specifically asking for input from nextgens because of his experience with > low level networking in general and Ian because of his experience with > Dijjer, and because he originally pushed for short timeouts. > This seems relevant: http://utopia.duth.gr/~ipsaras/minrto-networking07-psaras.pdf
I do not understand TCP well enough to be able to implement it though. What's going on exactly? We don't do cumulative ack's, so losing an ack is a real possibility. There are various options for more efficient acks, which could include some amount of acknowledging packets that have already been acked. How important is this?
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list [email protected] http://freenetproject.org/cgi-bin/mailman/listinfo/devl
