Wait, you're trying to send more data than the link can take? Then send UDP, throttle it at the local end with a drop-oldest qdisc. Then you get the effect of 'most recent data is best'. Anything more compilcated in terms of priority either needs a custom qdisc, or your application needs to not try and send more than the link can take.
The situation described is real and complex. For example I run an email service which caters for people using satellite phones (1,200 baud on a good day), but the whole point is that they don't need to change any settings when they jump on a 10Mbit leased line connection...
This is a total pain to optimise. Ideally I would like an API to be able to limit the congestion window on the local machine for a particular connection (which I don't think exists on either windows or linux?). This way the OS will report that the queue is full quickly to the local program without buffering up a ton of data.
The issue in my case is that you have two simultaneous streams in transit for email, one to receive new mail and one to send mail out. In the case of the sat phone it's possible to have net buffers which are 20 secs or so long and so when you send out a status message to say "email received successfully, send me the next one", it can end up queued behind a bunch of lower priority data for a VERY long time. Often these buffers are on the remote ISP end where you have very little control. This is a serious slowdown on a link which is costing you $1.50/min.
My main focus has been adjusting the protocol to be less interactive, but it would be nice to have more operating system support for these fringe cases
Ed W _______________________________________________ LARTC mailing list LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
