(With CC to devl@ this time) On Friday 2010-08-06 00:24 Matthew Toseland wrote: > e498d8d502a64e1413ebdf69e05ce0940d140d02 > - can item.buf.length be < end ? Yes, eg. if we haven't sent anything from this message yet, sent is empty, so end = Integer.MAX_VALUE.
> d49933fadd01ab44145dc8346fa43cb0d4812d76 > - is a default of 0 a good idea?? Not sure. I haven't seen any problems, but for now I've changed it to 250ms (minimum rtt returned by PacketTracker.twoRTTs()), so if it matters we will resend a lot less on startup. > ac10be3f2059c89e42e23de8613b86e46fd013ee > - how long will it take for us to go through 268M message ID's? it > should be safe to wrap as long as the packet-level delta is so large > that there is no possibility of confusion, so it doesn't affect > rekeying, correct? (Actually rekeying has to be separate from the > message sequence anyway ...) The testnodes I'm running right now will run out in 2 years (12h uptime, ~170k and ~85k ids), but then again they to nothing... It should be safe to wrap, both because of the packet numbers, but they will run out too. It looks like FNP uses per-key packet numbers, but doing it that way means they start over at unknown intervals, so they can't be used for checking the message ids (or can it be done?). > 1ad9015e0b642d52ce5096a1452b23068aaea19a > - packet sequence numbers appear to be per-SessionKey? are message > sequence numbers global (for a peer) while packet sequence numbers > are per-encryption key (and potentially per-transport as well)? They are both per-peer. Message ids have to be, packet numbers is related to the above point. > - IMHO this should be a rolling window, rather than being > periodically refreshed. I.e. you maintain a pointer within the > buffer, and when you accept a packet you move the pointer and update > the slots behind it. And because the IV is generated from the packet > number, you will need to use the offset of the match to tell you the > packet number in order to do the decryption. But maybe I'm wrong? Sounds good. I think I've got a reasonably good way of doing it, so it should be fixed soon. > 9c43896c682115f47ea2fc669bc7f6d5cb08c2aa > - HERE BE DRAGONS !!!! > - I spent a significant amount of time on issues related to this on > the old packet format. > - On the old packet format, we could not send packet N+256 until > packet N had been acknowledged. But we still needed to be able to > send ack's, and we don't want to busy loop. Hence if we can't send a > packet with a sequence number, we send one without a sequence number > (seqno=-1), containing only acks. The problem is that we can't reuse > the same seqno in the new packet format because the IV is derived > from the seqno and the IV must be unique for a packet. > - IMHO you do *not* need to take into account the receive window as > you do here. Packets are generally delivered in order, so you can > have a lot more packets in flight than the decryption window and > still have all of them decrypt correctly; and this is likely to be > the case anywhere where you have a high round trip time. > - Is there any other reason to arbitrarily limit the number of packet > sequence numbers in flight? [...] None that I know of, so I guess the limit can be dropped. > d5d5d6c52d1690be2872f07502cef9a45058c16b > - I don't understand why this commit is useful or necessary. > MessageWrapper's are all wrapping MessageItem's, aren't they? So they > will get told of disconnect anyway? PeerNode calls onDisconnect() for the items on the queue, but not for items that we've started to send. > 7d80c2ca4d28f7ae0a01bb515ad00543c2954c5d > - Can we optimise the sender size for high packet loss by e.g. trying > to complete existing fragmented sends, possibly one at a time, before > starting new ones? Assuming you meant the sender side, it shouldn't be to hard to do, even after it has been put into use. If you meant size, I've got no idea what you are asking... -- 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/20100809/d5472919/attachment.pgp>
