serf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bert Huijben" <b...@qqmail.nl>
Subject RE: svn commit: r1714297 - in /serf/trunk: buckets/event_buckets.c outgoing.c serf_private.h
Date Sat, 14 Nov 2015 11:36:10 GMT


> -----Original Message-----
> From: Greg Stein [mailto:gstein@gmail.com]
> Sent: zaterdag 14 november 2015 12:01
> To: dev@serf.apache.org
> 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, <rhuijben@apache.org> 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


Mime
View raw message