On Monday 09 August 2010 15:04:30 Martin Nyhus wrote: > 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?).
Not sure I see the problem ... The FNP packet numbers start over well before they would have wrapped (note that wrapping here means catching up with their starting value, not reaching 0). With CTR mode generation for the IVs, this is pretty important... Other related issue: If you are expecting the message numbers to wrap you need to make sure that it's possible in the code i.e. seqno = seqno++ & 0xfff... > > > 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. Hmmm. Message ID's have to be indeed. Packet numbers could be per-key, but it doesn't matter much, reusing the same packet number with a different key is safe. > > > - 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. Okay. So there is no packet allocation "window", which simplifies life a lot. There is a message ID allocation window, but being unable to add message ID's does not prevent old ones completing; the only difficulty there is avoiding busy-looping, which does require a wakeup for the PacketSender if we go from a state of being unable to add message ID's to being able to. How do you limit the memory used by the structures tracking the packets that we have sent and have not yet been acked? Ultimately I guess if the receiver never acks anything we will stop sending because of the message ID window. But what if he e.g. only acks even numbered packets? The content will be resent and eventually acked, but the old packets will never leave your buffer? One simple solution would be to have a window, and discard anything before X packets before the current, but never to block because of it i.e. always allocate a new packet number and delete the data about old packets if necessary, don't wait for acks. > > > 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. Ok. > > > 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... Sorry, I mean can the sender make optimal use of the receiver's buffer. And yes, you're right. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20100809/d9eac182/attachment.pgp>
