* Matthew Toseland <toad at amphibian.dyndns.org> [2007-10-27 00:48:42]:
> Various odd errors recently (PacketSequenceException for example) seem to > have > been caused by running several JFK negotiations simultaneously and all of > them succeeding. STS was stateful and therefore could only have one in > flight, but JFK can have more than one. So one completes, then another > completes; this exposed a bug which I fixed, but it is problematic as the > second connection will clobber the first. > Are those exceptions harmful ? what happens? we detect that the sequence number is invalid and wait for the initiator to resend it with a "fixed" sequence number ? Do we loose anything but time here ? > Options: > - 1) Introduce some state, resend the same message 2 after receiving the same > message 1. Bad: memory DoS. > - 2) Ignore the problem. It works, don't fix it. Probably what we'll go with. > - 3) Stagger the sending of the phase 1 handshakes. The problem is that we > may > have to keep firewall tunnels open, so we have to send to each address every > <30 secs. But there should be space within this to send to a few addresses... > - 4) Support multiple temporary connections. Drop according to a defined > order > in the noderef. > - 5) Support multiple permanent connections. Separate AIMD for each > connection, so messages can be distributed according to whichever connection > has the lowest RTT and has available bandwidth. > > Any comments? The current solution sucks. How long do we wait before sending the handshake to next ip? iirc we don't wait at all... Meaning that we will clobber the "fastest" link we have to a peer in favor of the crapiest one! Can't we ignore new calls to pn.completedHandshake if a link is already existing ? That sounds to be the simplest solution to me. NextGen$ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20071028/dd0f2379/attachment.pgp>
