I haven't fully digested your note, but a related issue: normally doing an RPC over TCP is fast, for some value of fast that is on the order of a few round trips. So if it doesn't work in say 5s when normally it's 100 ms, it probably won't. But the delay dynamics are hard to be sure about, with head-of-line blocking, although someplace in the code one can know about the most recent one. So, it should be possible to estimate when rpc-over-tcp is losing and give up faster than tahoe currently does. It's hard to believe there isn't significant prior work in this area, but I can't point to it off the top of my head.
FWIW, I've seen this issue too, with a server/client behind a lame firewall (I gave up).
pgplFSOBskDBw.pgp
Description: PGP signature
_______________________________________________ tahoe-dev mailing list [email protected] http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
