On Sat, 17 Jul 2010 18:07:56 +0100 Matthew Toseland wrote: > - How to make message ID re-use safe, or how to not re-use message > ID's and still not use unreasonable numbers of bytes. [...] > - We allow up to 8192 messages in flight. We use the top few bits for > flags. We recycle message ID's. ********* Is it safe to recycle > message ID's - even in the presence of replays and delayed packets? [...] > - Message seqno's are reused. ********* We need to seriously consider > this, I'm not sure it's safe, even with a packet-level window. How > can it be made safe? Safe = we get a somewhat delayed packet, it > contains a chunk from message 1, we can be confident that wasn't from > the previous message 1. I haven't been able to convince myself that reusing ids can be done safely, and not reusing ids would solve the issue of how many messages we can keep in flight, so using two bytes extra (based on your idea on irc some time ago) might be worth it, especially considering bulk transfers.
> - Acceptable length of an HMAC. [...] > - Use first 4 bytes of SHA256 as HMAC. ********* TOO SHORT ???? Maybe > should be variable depending on packet size? RESEARCH THIS! The length is in a constant, so it's very easy to change, but I don't know how long it should be. FNP uses the full SHA256. > - Appropriate window size for packet numbers. This might depend on what we do with the message ids, but other than that I think this is a question of how many sequence numbers we want to watch for. > - We still use one 4 byte ack and then 1 byte deltas. ****** We > should compress each ack relative to the preceding ack, not relative > to the first ack (and sort them, of course) Fixed in 4f08a3e13de550f0c15f910a8e23b73ac18592f4 > - Add SparseBitmap class to contain range tracking logic. Similar > code was in ReceivedPacketNumbers and temporarily in MessageWrapper. Using this in ReceivedPacketNumbers is on my todo-list, but after GSoC. > - ********** IIRC TCP resends immediately if it sees a later sequence > number? This reduces latency but will occasionally result in > unnecessary resends? I think what TCP does is this: If a packet > hasn't been acked after 4 RTT's (you can get this from > PeerNode.fourRTTs()), we resend it; and if we get an ack for a > packet, we assume those before it haven't arrived and resend them. I > may be remembering wrong, there's something about 1.5 RTTs somewhere? > Look it up, maybe on the wiki page? What the old FNP code does is > hideous, of course. I couldn't find the details on TCP at first glance, but improving the resend logic is on my todo-list. -- Martin Nyhus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20100727/deaf6276/attachment.pgp>
