> -----Original Message-----
> From: Greg Stein [mailto:[email protected]]
> Sent: zaterdag 14 november 2015 12:01
> To: [email protected]
> Subject: Re: svn commit: r1714297 - in /serf/trunk: buckets/event_buckets.c
> outgoing.c serf_private.h
>
> On Sat, Nov 14, 2015 at 3:36 AM, <[email protected]> wrote:
>
> > Author: rhuijben
> > Date: Sat Nov 14 09:36:08 2015
> > New Revision: 1714297
> >
> > URL: http://svn.apache.org/viewvc?rev=1714297&view=rev
> > Log:
> > Redefine the event bucket as a wrapping bucket, to remove dependencies
> on
> > implementation details on the 'aggregation' stream around the event
> bucket.
> >
> > Calculate total number of bytes read to increase event value.
> >
> > * buckets/event_buckets.c
> > (event_context_t): Extend state a bit.
> > (serf__bucket_event_create): Add start event and stream arguments.
> >
>
> What is the start callback for? You added that, but don't use it. And why
> is there bytes_read when it is (by definition) always zero. ?
On the start event it is always zeor, but it allows using the same callback for
multiple events.
>
> For that matter ... why even attempt to record bytes_read? That doesn't
> appear to be used. And it is missing bytes read via readline().
There is no specific readline implementation, so that will fall back to using
read and peek... which do handle bytes_read.
>
> I'm wary of the callbacks to start with -- that somehow normal bucket
> reading is not enough, and so "magic" needs to happen under the covers.
> (kinda like my query about hold_open)
As I already noted in my mail to Ivan we need accounting for http/2....
Or we can add yet another bucket type which does what this bucket does, and
adds bytes_read support.
In http/2 we need to strictly account for bytes send over streams. If we wrap
this bucket over the split buckets (limit on steroids) added yesterday that
will handle all these cases in a generic way.
In http/2 you are only allowed to send DATA frames upto the window limit that
is managed by the receiver. If you go one byte over the limit the stream will
be closed with a RESET, while you can't keep 'a safe margin', as a receiver
might use this feature to receive data very slowly.
HTTP request and response bodies are transferred over this system.
Bert
