More recent changes: zidel/packetFormat: a0be689df7860dca5cc43b0ef949aeff7cb511c1 to 6a1f69c42d0f013e77253a3eb1bb39cc27e75c95 - Report when sent packet, etc - sentPacket(), reportOutgoingPacket, reportNotiificationOnlyPacketSent. - forceGrab() on throttle when sent packet. - Report resent data at lost() time: Add up the bytes lost when the packet was lost, which will now need to be resent, and subtract the ranges we would have acked. - Try all 3 keys if possible - current, previous, unverified. - Don't keep trying to add messages once we have maxed out the other side's buffer or we cannot allocate a message ID. - Logging. - Synchronization. - Sort message fragments before sending the packet, to maximise opportunities for message ID delta compression. - Use an integer for message ID's, not a long. They are only 28 bits. - Record finished message ID's, drop fragments from already finished messages. - Logging. - Don't remove bytes from other side simulated buffer if we've already had an ack for the message. - Set default RTT of 250ms. - Fix unit tests. - Check that the first fragment in a packet has a full message ID. - Use a nonce for CTR mode when computing the IV. - Fix: If receive buffer is full, skip the fragment and don't ack the packet. (We were supposed to be doing this but weren't) - Don't create the fragment at all if it won't fit in the buffer. - Log when changing the message length. - Get a sequence number only after we have stuff to send. - Don't increment the sequence number counter if we can't use the seqno due to the packet window (this would make things even worse). - Move ack checks into addAck().
bd514e622e0d9354c2240f7703d56515dbafa156 - does throttling work? is forceGrab used by the other path on sending a normal packet? - Why do we subtract the ranges we would have acked? 653d5a6178b353b56babc3d6da04a2d4499abcb5 - Do we promote the unverified tracker? adf6a1473b11916e5de3f57c982c399d26eacecf - Sorting message fragments is good, but it means that the number of bytes used can change because of delta compression of message IDs. Is this a problem? 5dda461561447f89e45fd4500a8fc6b318d5e166 - Can finishedMessages be exploited for a slow memory leak? 4d1a9c19d80ecb498cb506e17ebbe957c23b3ce4 - Do you have a unit test / simulator for this logic? Any sort of leak could become a big problem ... f37c768f8590f1bca472c4eb66313c892a7f455d - Normally the counter itself is at the right end not the left end in CTR mode AFAIK. Wikipedia seems to allow for any combination mechanism though... General questions: - Padding. Do we have padding, as an option when there is nothing to send??? - Multiple ranges from the same message in the same packet. Possible? Major remaining issues from previous correspondance: - expected packets: rolling window? - busy-looping when can't allocate a message ID due to other side's buffers -------------- 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/bfb36e39/attachment.pgp>
