On Monday 17 March 2008 15:30, Robert Hailey wrote: > > On Mar 15, 2008, at 1:03 PM, Matthew Toseland wrote: > > > Not convinced by _abandonedTickets: > > > > 1 new ticket > > 2 new ticket > > 3 new ticket > > 4 new ticket > > 2 times out > > 3 times out > > space to send (1) > > 1-2 = -1 so we don't send > > space to send (2) > > 4-2 = 2 so we do send 4 > > > > We could avoid this by using _packetSeq <= (_thisTicket- > > _abandonedTickets) ... > > but then it is only approximately ordered: > > You are right about the abandoned tickets, and you have already fixed > the comparator (>= not <=) in r18544. > > > > > 1 new ticket > > 2 new ticket > > 3 new ticket > > 4 new ticket > > 5 new ticket > > 3 times out > > 4 times out > > space to send (1) > > 1-2 = -1, 2-2 = 0, both < 1, so we send either 1 or 2 > > space to send (2) > > we send the other one > > > > Obviously this will only happen if some packets have different > > timeouts. > > However this is unavoidable if we switch trackers when a node changes > > address. Apart from that (which is rare), we have a 5 minute timeout > > for bulk > > transmits (noderefs, UOM, node to node data transfer) and a 1 minute > > timeout > > for block transmits (CHK requests, CHK inserts). Meaning if we > > unexpectedly > > lose bandwidth for a short period, we will probably timeout block > > transfers > > but not bulk transfers... > > The incidence of that happening is remote. Even given your counter > example above, perfect packet ordering is resumed after a small hiccup. > > > Or we could explicitly track the packets to send. A DoublyLinkedList > > being the > > obvious option (not the java.util version, with the freenet.support > > version > > we get O(1) removes). A TreeMap would allow us to prioritise packets > > by their > > deadlines. Is this a good idea? Should I implement it? > > Ehhh.... I don't think so. Mostly because it seems like overkill, > starting to re-implementing the link layer over the message layer. > > But on the other hand... if freenet will ever have realtime/guaranteed > transport we would need to unfairly favor some block/ssk streams, right? > > In any event, after r18544 (Doh, >=), starvation is solved (as best I > can tell); priorities is certainly a "feature," and guaranteed > ordering (between different transfers) will probably never be truly > necessary. > > Good catch, I had already convinced myself that '==' was right, > although, a bit intimidating.
Actually, I'm not sure we're finished here. What we really want to do, to minimise the chance of a timeout, is to alternate between the active transfers. With the code you implemented, if a block is in store, all of its packet transmits will be queued at the same time and therefore all other transfers to the same peer will wait until they have all been sent, which given bandwidth limiting could be a long time. Suggestions? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20080319/2b9cb446/attachment.pgp>
