cURL / Mailing Lists / curl-library / Single Mail


Re: Adding client WAN support to libcurl

From: Pavel Orehov <>
Date: Fri, 11 Feb 2005 19:59:43 +0200

May be i was not so clear, sorry. These features only needed for my testing
purposes, but if you see them usefull for other purposes you may add them
permanently. I want the following features from libcurl and this is not
correct client behavior:

- Delay between transactions. For example if i have X transactions in multi
stack, i want libcurl to perform these X transactions with delay of Y
miliseconds between each other. It might be done for example by setting some
parameter with curl_setopt on handle.

- Send/Receive data in blocks on TCP layer. For examle i want to define for
some transaction in multi stack parameter of "X:Y:Z". X - means how many
bytes to send/receive. Y - means periodicity of X bytes to send/receive in
miliseconds. Z - means after which block to drop the TCP session (0 -

I did not found these features in libcurl, fix me if i wrong. I need from
you, libcurl developers, points in code (filename, function) where i can add
these features. Or if you see them usefull you can add them to libcurl
features request and i will be glad to get them ready in next libcurl


----- Original Message -----
From: "Daniel Stenberg" <>
To: "libcurl development" <>
Sent: Friday, February 11, 2005 4:18 PM
Subject: Re: Adding client WAN support to libcurl

> On Fri, 11 Feb 2005, Pavel Orehov wrote:
>> - Delay between transactions
> In what way is this libcurl's concern?
>> - Send/Receive data in chunks on TCP layer
> In what way doesn't libcurl already send/receive data "in chunks" ?
>> - Dtop transaction after some defined time period
>> - All these features should work via HTTP, HTTPS, FTPoHTTP protocols
> I thought they already were.
>> If first look i see that all read/write to socket actions are in one
>> function, i just want to be sure that i am not missing something.
> Well, doing it there will work if you're only using the easy interface.
> Which then also would make it pretty certain that I wouldn't accept such a
> patch into the main sources...
> If you're using the multi interface, you need a much better approach, and
> I'm not accepting patches that deliberately aren't taking that into
> account.
> --
> Daniel Stenberg -- --
> Dedicated custom curl help for hire:
Received on 2005-02-11