On Saturday 08 March 2008 12:47, Michael Rogers wrote: > Matthew Toseland wrote: > > RFC 2861 is rather late in the day for TCP. If we had set out to copy TCP we > > would likely not have seen it. > > So what's your point - that because TCP has bugs, anything that's not > TCP won't have bugs? We're the only people looking for bugs in Freenet. > Lots of people are looking at TCP.
Only that it probably wouldn't have solved this specific problem. There is endless literature on TCP and I at least don't have time to keep up with it, and a wide range of implementations exist. > > > Why should either affect the FNP layer? The link crypto won't affect it now. > > True. > > > The congestion control does, but won't with the new transport layer because > > in the new transport layer all messages will be subject to congestion control > > and output limiting. > > Even with the new transport layer, congestion control needs to be aware > of weirdness caused by not splitting messages across multiple packets. > For example the fix in RFC 2861 wouldn't work because sometimes we don't > use the whole window even though there's data waiting, because there > isn't room in the window for a whole message. Fair point. However, streams can be squeezed in *almost* anywhere, and any large message will be changed to be a stream. > > > Transport plugins are of no use if it takes six months to implement and debug > > one. > > Yes, exactly... > > > Obviously we will need several different interfaces for different classes of > > transport. > > Agreed - maybe three classes: "IP-like", "TCP-like" and "TLS-like". The > first just provides an unreliable flow of (possibly very small) packets. > The second provides a reliable, ordered, congestion-controlled stream. > The third provides an encrypted, authenticated, reliable etc stream. > > Then we have a default TLS-like layer that can use any TCP-like plugin, > and a default TCP-like layer that can use any IP-like plugin. > > > AFAICS all you need > > to do is pass in some information about the desired packet sizes, which the > > node will then try to meet on outgoing packets (just as in my proposal you > > are replying to), and it will pass packets to the plugin. > > TCP exists for a reason: so applications don't have to worry about stuff > like packet sizes. Let's say we have an RTP plugin that can only deliver > 160 bytes per packet. Should we redesign FNP around the needs of the > transport plugin? No, we should have a layer in between. Big messages shouldn't be messages, they should be streams. This was in my original proposal. We will be able to use 160 bytes per packet as long as we have streams that can be sent in arbitrarily small chunks, and we don't have any really big messages. There are good reasons for both decisions even without transport plugins, as I have explained. > > >> Big packets will be fragmented rather than dropped, and occasionally all > >> the fragments will get through. That's the problem, in a way, because if > >> big packets were always dropped we could work out the MTU for ourselves. > > > > No, that's not the problem. That sucks, but it doesn't suck as bad as the REAL > > problem, which is that for a lot of connections, fragmented packets are > > dropped, either more often, or more usually always, because of hardware > > firewalls along the route. > > Exactly - if they were always dropped we could work out the MTU by > gradually increasing the packet size, We will, but right now we don't, and bad things happen as a result. > but because they sometimes get > through we just see horrible performance. Maybe we could guess the MTU > by recording the sizes of dropped packets and looking for a threshold, > but once again we'd be reinventing the wheel - TCP already discovers the > path MTU. TCP does it the same way a zillion other protocols do, by sending packets with dont-fragment set. Which we can't do in java. Well maybe we can, but it means even more JNI code. Also, does it require root/raw sockets? > > Cheers, > Michael
pgpT0X9To98m6.pgp
Description: PGP signature
_______________________________________________ Devl mailing list [email protected] http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
