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@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
