#ls2 (irc2p) | #ls2 I2P Protocol Development Discussion - Next Meeting Monday, October 9th 6:30 UTC

zzz you should have gotten _10_ packets after the session confirmed: 3 retransmitted session confirmed (2 pkts each) and 4 data packets (orignal + 3 retransmitted)

zzz how many did you see, and what sizes?

orignal I got first sessionconfirmed then sent ack

zzz you should see 10 packets after that in the next 10 seconds. actually 11, including the termination

orignal no I didn't see anything else

zzz ^^ you listed two above.

zzz you have the sizes?

orignal sorry, 4 more from you

orignal I will start printing sizes

orignal 6 totatlly

orignal let me investigate

orignal defiently it's wrong state

orignal and keys

orignal looks like I didn't receive SessionConfirmed from you

orignal when you start sending data do you wait for ack from me?

zzz no, spec says you immediately send data after session confirmed

zzz if we waited that would be another RTT

zzz again, I sent two session confirmed packets, then 10 more: 6 session confirmed retx, one data, 3 data retx

orignal so, can I assume that

orignal <orignal> SSU2: Unexpected message type 99 instead 2

orignal is a data message?

orignal let me forumate differently

orignal is it possible to receive data message instead session confirmed?

orignal e.g. I expect session confirmed it was lost on the way

orignal and I receive data

zzz of course.

orignal I do it differently in i2pd

orignal I don't send data until I receive ack for sessionconfrimed

orignal and keep resending sessionconfirmed

zzz packets may be lost or reordered

zzz I'm retransmitting 3 things at once:

zzz session confirmed fragment 1

zzz session confirmed fragment 2

zzz data packet

orignal I defintly receive data while expect sessionconfirmed

zzz that's not what the spec says, and it's inefficient because you're wasting a RTT waiting for the ack

zzz can you handle session confirmed fragments in either order?

orignal no sure

zzz not sure?

orignal if I receive second fragment I wait for first

orignal but what is with RTT?>

orignal you lose it during hanshake only

zzz if you wait for ack of sess confirmed before sending data, that's an extra RTT of delay

zzz we specifically designed SSU2 to NOT have that extra RTT

zzz it's very important to minimize session setup time

orignal fine I will change it

orignal it's clear now what's the problem

zzz not clear to me )) please explain

orignal I recognize wrong message and try to terminate a session immediately

orignal assuming (wrongly) that I'm supposed to receive SessionCreated only in this state

orignal *SessionConfirmed

zzz ok so one fragment of session confirmed is lost or reordered, you get data message, can't decrypt, and terminate the whole thing?

orignal yes

orignal when I receceive somthing that is not SessionConfirmed I assume that the session is malfuctioning

zzz ok that makes sense

orignal it a fragment is lost it's a problem

orignal I will wait for it's restransmission

orignal that problem is Data

orignal and what I'm supposed to do with that data packets? drop them?

orignal since I don't know they are data packet

orignal because I don't have keys yet

zzz what the spec says (and what I do), is if you haven't received session confirmed yet, and you get an undecryptable packet, queue it

zzz once you get session confirmed, try to decrypt everything in the queue

orignal will try to implement it this way

orignal later

orignal let me just drop them first

zzz spec says it's optional, but I think it's working for me

orignal it's fine but let me fix it first

zzz yup

zzz <orignal> if I receive second fragment I wait for first

zzz but are you saving the second fragment?

orignal no ))

orignal not implemneted yet

zzz github.com/PurpleI2P/i2pd/blob/16290bf66f8f6d65bb142cf3f52de1b7d7eb214a/libi2pd/SSU2Session.cpp#L752

zzz you should do that too :)

orignal I know

orignal can't do everything at the time ))

zzz ok

zzz in general, don't fail a session at any point based on an unexpected message type, just throw out the packet, to prevent packet injection attacks

orignal good point

orignal but it's about session confirmed only

orignal btw, tell me how to make long RI?

orignal just add some long param?

orignal want to try it

zzz spec section "Session Confirmed Fragmentation"

zzz oh, you mean for testing?

zzz look at ~Akx, you will see :)

zzz oh, you mean for testing?

zzz look at ~Akx, you will see :)

orignal yes

orignal will do

orignal want to publish fragmented SessionConfirgme

orignal commited

orignal should handle SessionConfirmed properly

orignal zzz, Orion said that ImQC is his

orignal another funny thing I limit param by 255 characters ))

orignal hence I can't add so long param

zzz they are less than 255

zzz they can't be more, because of the Mapping encoding length is 1 byte

orignal x is long

orignal I see x, y, z

zzz x is about 180 chards

zzz it's impossible to be > 255

orignal yes I see now