httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <>
Subject Re: tracing core in/out and socket I/O
Date Sat, 12 Jan 2002 19:24:20 GMT
On Sat, Jan 12, 2002 at 08:25:48AM -0500, Jeff Trawick wrote:
> For putting this in a module, the first thing I thought of was
> replacing the code that creates a socket bucket so that it instead
> creates some tracing-socket bucket registered by my module.  But that
> code is in core_input.  It would be crazy to try to replace
> core_input.

Why?  I'm not at all certain why that is crazy.  All you would
need to do is:

         /* seed the brigade with the client socket. */
         e = apr_bucket_socket_create(net->client_socket);
+        e = apr_bucket_socket_debug_create(net->client_socket);

We could also extend bucket_socket_create to take a debug flag.
The only thing that a socket_debug bucket needs to do is shadow
the real socket bucket.  It could just save a copy of all buckets 
that are returned by the real bucket.  All operations on this
bucket would happen on the real bucket first than any buckets 
that may be returned to the user are stashed away.  (This bucket
would actually have a brigade inside of it.)

In fact, we could even call it a shadow bucket.  I do like this 
approach a bit better as it follows our abstractions better:

         e = apr_bucket_socket_create(net->client_socket);
+        e = apr_bucket_shadow_create(e);

The APR-util code dealing with brigades and buckets would have
to be examined to see how we could handle this cleanly 
(apr_brigade_normalize scares me).  But, perhaps the APR-util 
code could have knowledge of a shadow bucket and do the right
thing there if it can't handle it nicely currently.  I dunno.

In core_input_filter, the tricky part may be getting it to 
realize when an EOF has occurred with this bucket.  Ideally, 
the debug bucket can't just disappear like the real socket 
bucket does.  We want this bucket to stay around because that
way we can examine the read data even after all of the data
has passed through core_input_filter.  But, I don't think this 
is an insurmountable problem.

I don't see a particular need why this has to be in the APR
network I/O code itself since the socket bucket seems a 
completely logical place for this.  At least in my warped 
view.  =)  However, the devil is in the details.  

Thoughts?  -- justin

View raw message