On Sun, Jul 10, 2005 at 08:49:13AM +0100, Ed W wrote: > >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... Ah, I was picturing voice over a low-latency, low-speed link. Now I can understand what you're trying to acheieve. Is that 1200 baud each way? Or do you have to alternate up and down somehow? > 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. Indeed. For TCP, you could use setsockopt with SO_SNDBUF maybe? However, I'm not sure this is what you want. > 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. 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. eg. If you're doing POP3 and SMTP, you make sure any to-tcp-110 or tcp-ack-only packet is dequeued before any from-tcp-25 packets. You'd also need to jack the receive window right up, or wait for TCP to figure that out for itself. > 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 This is actually a common case, and often cited as a great big hole in TCP/IP's traffic algorithms. I know, it was a question on the exam. ^_^ -- Paul "TBBle" Hampson, on an alternate email client. _______________________________________________ LARTC mailing list LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
