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. -- Robert Hailey
