curl-library
Re: How to set the size of the send buffer?
Date: Wed, 23 Oct 2002 13:06:31 +0200
Thanks for your explanations. The problem we have is slighty different. We
have different lines with differents Qualitys. The problem is , if the line
has a lot of noise (Poor Quality) for us is better to copy by small
fragments instead big chunks. In fact the final idea is to calculate in real
time the number of failed attemps and then if one of the destinations
achieved a lot of them, then try to adjust the buffers to low size to avoid
the noise in the line. This well be done dinamically.
Thanks a lot for your pattient, but as you see this problem is very specific
and we are working with this kind of problems during several years and i see
if i do it manually (To reduce the buffer) it's works really fine.
Guido.
----- Original Message -----
From: <RBramante_at_on.com>
To: <curl-library_at_lists.sourceforge.net>
Sent: Friday, October 18, 2002 2:51 PM
Subject: Re: How to set the size of the send buffer?
> Ftp uses TCP as its delivery mechanism so it is intrinisically
> stream-based. UDP is more for delivery of blocks or packets of some fixed
> length.
>
> As Daniel mentioned, I don't think setting the TCP stack's send buf size
> will really accomplish what you want to achieve. Setting the sendbuf
> doesn't force the TCP implementation to send only certain size chunks onto
> the wire at any one time, it is just a suggestion for how much the TCP
> stack will buffer in its pending send queue, and even there, it is only a
> suggestion to the stack, it does not need to abide by it on many
> implementations.
>
> You probably would need to implement some rate-limiting algorithm that
> would possibly work by blocking in your read_callback function, i.e. you
> maybe have some timer and keep a tally of bytes read by curl (and assume
> they have been put on the wire although this may not technically be true,
> e.g. when you write() to a TCP socket, the return value indicates the
> amount of data the underlying stack has accepted for delivery but it does
> not mean it has actually successfully deleivered it to the perr yet).
> Anyway, if your algorithm determines that data is being written "too fast"
> you could put a sleep() of some value in your read_callback() to slow down
> the transmission.
>
> This is just a theory, not really sure if it is all that clean or how
> accurate your algorithm could be to make this useful. Any other thoughts
> as I have been kicking around the idea of possibly trying to "rate-limit"
> transmissions as well. Ideally, TCP's windowing mechanisms should provide
> enough built in flow control and tuning, but some people want the ability
> to further tune the i/o usage of individual applications for whatever
> purpose.
>
>
>
>
>
> "Guido Reina" <guidoreina_at_isdn-si.com>
> Sent by: curl-library-admin_at_lists.sourceforge.net
> 10/18/2002 03:15 AM
> Please respond to curl-library
>
>
> To: <curl-library_at_lists.sourceforge.net>
> cc:
> Subject: Re: How to set the size of the send buffer?
>
>
> I want to send to the FTP server blocks no bigger than <n> bytes (in case
> the FTP server has a slow line), does libcurl do it automatically?
>
> Thank you very much for all your effort, you cannot imagine how much you
> are
> helping me.
>
> Guido Reina.
>
> ----- Original Message -----
> From: "Daniel Stenberg" <daniel_at_haxx.se>
> To: "libcurl Mailing list" <curl-library_at_lists.sourceforge.net>
> Sent: Friday, October 18, 2002 9:03 AM
> Subject: Re: How to set the size of the send buffer?
>
>
> > On Thu, 17 Oct 2002, Guido Reina wrote:
> >
> > > Is there a way to set the size of the send buffer (for FTP)? I have
> seen
> > > that I can set the size of the receive buffer but not of the send, is
> this
> > > possible?
> >
> > Hm, can you please elaborate on what you want to achieve? You return the
> data
> > that curl uses for upload, why do you need to care how big its internal
> > buffer is? Changing the upload buffer size wouldn't change much.
> >
> > --
> > Daniel Stenberg -- curl, cURL, Curl, CURL. Groks URLs.
> >
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> >
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
>
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
>
-------------------------------------------------------
This sf.net emial is sponsored by: Influence the future
of Java(TM) technology. Join the Java Community
Process(SM) (JCP(SM)) program now.
http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0002en
Received on 2002-10-23