2013/9/16 Matthew Toseland <[email protected]> > On Mon, Sep 16, 2013 at 07:51:09PM +0400, Vladislav Sterzhanov wrote: > > - Fixed the cruel file-transfer bug. Made a pull-request and merged into > > freenet-upstream > > This is included in build 1456. > > > - Introduced, reworked and tested the means for cumulative > acknowledgements > > __________________________________________________________________ > > > > The most major limitations of the upstream-fred's acknowledgement scheme > > are the following: > > - It can not ack more than 255 packets in a single message > > - It can not ack the packets which sequence numbers vary by more than 255 > > (actually, the current codebase does not allow to ack ANY packet, which > > sequence number is more than the sequence number of the First packet in > the > > list) > > IIRC we keep them in order, so we can acknowledge any sequence of up to > 255 packets as long as the offsets are less than 255 for each one. We can > add packets to the beginning (changing the first packet seqnum) as well as > to the end. But yes to the main point here. > > > - It should allocate a 1-byte offset in the return-packet for Each packet > > that it acknowledges > > Meaning it is inefficient. Right. > > > > I proposed the solution for all 3 points with the series of commits to > the > > transport-layer-improvements branch in my repository (found here, as > usual: > > https://github.com/Quadrocube/fred-staging). It dramatically reduced the > > amount and size of packets needed to be send-back to ack each of the > > incoming packets. Stress-tested it by means of the toolset created at the > > first part of the summer - in combination with the bugfix of the > > PacketSender bug, it was able to transmit the 100Megabyte file without a > > single loss in local network at the speed of 550KiB\s (1MiB\s if remove > the > > artificial limit on the outstanding packets in BulkTransmitter). There > are > > still some useful modifications that can be done in the acknowledgement > > area (such as dub-acking some packets if it doesn't modify or even > reduces > > the byte-cost), so currently working on it. > > I look forward to your pull request! Let me know if you need any more help. > > Impressive speed gains - is this from the PacketSender fix or the ack > changes? > > The biggest contribution into it was of course the PacketSender fix (since the reverse-flow of ack packets in the conditions of LAN and one-side-transfer (the transfer is held only from one side to another, the second one only acknowledges packets) is quite little comparing to the flow of direct data-caring packets). Want to test it a bit more on a remote machine to watch on the impact of cumulative acks on lossy links.
> _______________________________________________ > Devl mailing list > [email protected] > https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > _______________________________________________ Devl mailing list [email protected] https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
