Re: Actually testing the non-blocking code is all of libcurl
Date: Thu, 14 Jun 2007 23:22:16 +0200 (CEST)
On Thu, 14 Jun 2007, James Housley wrote:
> What is rolling around in my head right now is a very simple proxy program
> that would delay packets. The command link might look like
> proxydelay <4|6> <listen port> <connect port> <delay time>
> Where using ipv4 or ipv6 would start listening on localhost TCP port <listen
> port> for a connection. Once a connection is made it would then connect to
> localhost TCP port <connect port> . Once that is done it would start
> listening for data. When it received a packet on either the "listen" side
> or "connect" side the program would then delay <delay time> ms before
> sending it out the other side.
Yeah, it is a great idea to use this approach to slow down, or even completely
stall, connections to better be able to test such conditions.
> Using the for both FTP streams would be tricky, but may still be able to be
The FTP connections are already made to and from "sockfilt", and that tool
could be extended to offer these bandwidth limiting features as well. I think.
> This probably won't be able to trigger blocking on write by libcurl, but
> will produce blocking on read.
It could still block writing too, but it would of course require writes of
some size so that a "slow" reading end really has an effect.
-- Commercial curl and libcurl Technical Support: http://haxx.se/curl.htmlReceived on 2007-06-14