cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: pycurl update for multi interface

From: Daniel Stenberg <daniel_at_haxx.se>
Date: Wed, 9 Oct 2013 23:16:44 +0200 (CEST)

On Wed, 9 Oct 2013, Dima Tisnek wrote:

Can I just remind you that we don't top-post on this list!

> I'm sure someone will find use for penalty values.
>
> I don't think it's easy to use them right: only get requests are pipelined,
> server "decides" on download and especially chunk length, then the client is
> probably interested in how long the transfer is going to take rather than
> bytes transferred, so client needs to keep track of download speed and vary
> the penalty size according to current network conditions. seems a bit
> complicated, does it not?

To make them *optimal* you might need to do that, sure.

The question is rather in my view: are the options helping HTTP pipelined
operations or not? And if yes, how else would we offer them? I really can't
think of a better unit than actual byte sizes (and we couldn't come up with
any built-in sensible rules or limits that would work for everyone). If you
don't think they help, then you can just ignore them. I talked to browser
implementors, they said such options are needed.

We have hundreds of options in libcurl. I'm the first person to agree that
several of them are tricky to use in general ways to make every single
transfer optimal. But I don't think the options are necessarily to blame for
that. I think the reason is instead mostly the fact that these protocols,
implementations, servers and the Internet as a whole is a tricky environment
to operate in. Not to mention when you use the library in special-case closed
environments where you can tweak things for a particular situation.

I think we have to live with a few complicated options.

> I on the other hand am more concerned in making sure only N sockets are used
> at most any given time and max total up/down bandwidth used across multi
> handles. requests can wait, additional latency can be ignored. perhaps the
> two use cases are clearer now?

Those are completely different concerns but perfectly valid, sure. I think we
are also trying to cater for them with several options and features.

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html
Received on 2013-10-09