Re: [LARTC] Re: RFC - bandwidth optimization idea

[Ed W <lists@wildgooses.com>]

>Assuming you can send both ways simultaneously, or at least guarantee
>some traffic time outbound no matter how busy the inbound traffic,
>you would surely have to pipeline your commands in order to get any
>kind of efficient use out of a high-latency link like a satellite link.
>Otherwise you lose 2x round-trip-time of incoming data stream while
>you request the next item.
>
>In this situation, you would want the OS buffers to be as full as
>possible so the minimal time possible is spent receiving, but using
>a traffic-shaping solution so that the most important stuff (acks
>and commands) goes out in preference to whatever else you're sending.
>  
>

Yes you do want to pipeline, but you still don't want the OS buffers 
full as possible.  Consider that you might want to know a message was 
sent successfully before sending the next message, but at the same time 
you have the pipe full with downloading new messages.  The OK which says 
the message was sent OK can be behind 15-20 seconds worth of downloads - 
hence you have to wait a long time before you can start sending the next 
message!

Also you can't use any kind of QOS here because the hypothetical 15-20 
second buffer is at the remote ISP end. (Who are not cooperative)

It's a tricky situation all you can do is figure out how to keep 
changing your protocol so that you don't ever need to hear a reply 
before you continue sending.

Anyone wants to buy it then drop me a line! 

:-)

Ed W
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc