On Friday 07 March 2008 17:33, Michael Rogers wrote: > On Mar 6 2008, Matthew Toseland wrote: > >Proposed solution > >============= > > > >All big messages are converted into streams. Small messages such as > >FNPAccepted should remain as messages. > > Can I make one last, futile appeal to use a stream-oriented transport layer > rather than a message-oriented one? > > Advantages: > * Makes it easier to copy TCP's good bits instead of reinventing the wheel
Much easier? > * Well-defined interface between the transport layer and the FNP layer In the sense that messages are never reordered, yes. > * Transport plugins won't break when FNP changes and vice versa I don't undestand why this would be an issue. We won't be passing Message's to transport plugins, certainly not for most transport plugins. We will provide a framework that makes it easy to write transport plugins, which your plugin can feed its parameters into. > * Transport layer problems like small MTU can be isolated from FNP Messages really ought to be small. This will be the case with the changes I have suggested: e.g. SSK data (including headers) will be a stream. > * Makes it easier to write stego transports Marginally. A lot of interesting stego tranports are packet based. > > Disadvantages: > * Packets can't be processed out of order Once messages have been assembled into a stream, they cannot be reordered. Would you still have packet level retransmission, or some sort of range retransmit scheme? What exactly does TCP do? If we send a packet which is over the safe packet size, what happens? Is it exactly the same as it is now? In the current scheme, we'd send the rest of the maximum window, and timeout and have to resend it; that's what would happen in the new scheme too. Not the congestion window, the maximum window (128 packets now, 64k with the new transport layer). So we can keep sending messages while we retransmit the packet repeatedly, and eventually give up on it, tell the other side that, and split it up and send the messages in smaller packets. In your scheme, what happens? This is probably the worst case in terms of increased latency. > > We probably need to stick with UDP for firewall traversal, but in my > opinion we should build a TCP-like layer on top of UDP. It's quite possible > to send small messages over TCP with reasonable latency - SSH, Gnutella and > Skype all do it. And it's no harder to multiplex multiple message streams > over TCP than it is over UDP, considering that we have to share crypto and > congestion-control state between the streams anyway. Reasonable, yes. But it will always be more than a real out of order transport. > > Cheers, > Michael -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20080307/b89b7eef/attachment.pgp>
