[freenet-dev] r18536 - trunk/freenet/src/freenet/io/xfer

[Robert Hailey]

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