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
I'm not sure I follow the problem, but if you're saying that one
stream should have priority over the other, it seems you could do
that with two different queues, one with priority over the other.
Or something like sfq could at least prevent one connection from
waiting for the other to send a
From: [EMAIL PROTECTED] (Paul Hampson)
Wait, you're trying to send more data than the link can take? Then
No, of course I don't expect to send more than the limit.
send UDP, throttle it at the local end with a drop-oldest qdisc. Then
you get the effect of 'most recent data is best'.
From: Andreas Klauer [EMAIL PROTECTED]
Doesn't every QDisc work that way? When the kernel wants to send a packet,
it calls the appropriate dequeue() function in the QDisc. I'm not a kernel
developer so this guess might be wrong.
That's correct, but this operation takes a packet from an
