On Tue, 5 Mar 2002, T. Bharath wrote:

> >The callback would be named something like "data_sent_to_peer" and I'm
> >planning to make it get called *after* each single function that sends data
> >to the remote server. The prototype would look similar to this:
> >
> > int
> > data_sent_to_peer(CURL *handle, char *dataptr, size_t size, void *clientp);
> >
> >The 'dataptr' would point to data and the 'size' would indicate how many
> >bytes of data that was just successfully sent. The 'clientp' pointer is of
> >course a custom set pointer that libcurl ignores, in the style of the other
> >callbacks.

> It definitely is useful especially in protocol traces to see what was sent
> from the client side. But i think size should point to the no of bytes in
> dataptr (some of the protocol data may not be null terminate) or may be we
> can add this as an additional param. If size contains the data successfully
> sent, it can be less than dataptr size as its possible that not all of our
> data has been written to the network

Correctomente, 'size' will be the number of bytes "just successfully sent"
(as far as we can tell). The 'dataptr' may point to more data than what the
size argument says, but this callback function won't be able to tell or know
this. I can't see any point in letting the callback know this either.

This is of course just as you say, because we might have read a large chunk
from a file but were only able to write a small piece of it to the network.

The data passed to this callback would also be unencrypted even in the cases
when we use SSL or kerberos.

In cases like with FTP, we have two different connections that data gets
written to, is there any point in trying to make the callback aware of this
fact?

-- 
    Daniel Stenberg -- curl groks URLs -- http://curl.haxx.se/