cURL / Mailing Lists / curl-library / Single Mail


Re: Actually testing the non-blocking code is all of libcurl

From: Daniel Stenberg <>
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
> done.

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:
Received on 2007-06-14