Protocol Philosophy

[Chris Werner <Ch...@unicel.com>]

Mod_perl list,   Apache 2.2.0 mod_perl 2.0.2

I have been working with an alternative protocol implementation for apache
for some time now and [as would be expected with a perl based tool] I have
found many ways to accomplish the same task. I am asking about the
philosophy or design intent of these filters.  I have read the provided
docs, copied, executed and modified the examples.

My best understanding of the intent is that the PerlProcessConnectionHandler
sets up the connection, and issues a request to the PerlInputFilterHandlers
for data. The PerlInputFilterHandlers gets the raw data in a bucket
brigade(s) and have first crack at massaging the data. Here we handle data
overrun, underrun, and reorder bucket (and brigade) contents to have
reliable contents. The PerlInputFilterHandlers do not send this data
downstream per se, instead they respond to requests for incoming data from
downstream and answer these requests by manipulating the bucket brigades
supplied by the PerlProcessConnectionHandler. The
PerlProcessConnectionHandler does the work of implementing the protocol;
here state machine actions and database accesses are performed. The
PerlOutputFilterHandler fills out bound bucket brigades with outbound server
side protocol messages.

That is my best understanding of how a protocol implementation should be
constructed... 

As the provided examples show, work can be done, for example, in the
FilterHandlers.  What was the original intent? Is there ever a case where it
would make sense to perform database queries/updates or hold state machine
logic external to the data stream in a FilterHandler? 

Making things work is not a problem. I can always make things work. What is
the prevailing wisdom as to how things should work?

Thanks in advance, and kudos for a well built tool,
Christian Werner

Re: Protocol Philosophy

[Stas Bekman <st...@stason.org>]

Chris Werner wrote:
> Mod_perl list,   Apache 2.2.0 mod_perl 2.0.2
> 
> I have been working with an alternative protocol implementation for apache
> for some time now and [as would be expected with a perl based tool] I have
> found many ways to accomplish the same task. I am asking about the
> philosophy or design intent of these filters.  I have read the provided
> docs, copied, executed and modified the examples.
> 
> My best understanding of the intent is that the PerlProcessConnectionHandler
> sets up the connection, and issues a request to the PerlInputFilterHandlers
> for data. The PerlInputFilterHandlers gets the raw data in a bucket
> brigade(s) and have first crack at massaging the data. Here we handle data
> overrun, underrun, and reorder bucket (and brigade) contents to have
> reliable contents. The PerlInputFilterHandlers do not send this data
> downstream per se, instead they respond to requests for incoming data from
> downstream and answer these requests by manipulating the bucket brigades
> supplied by the PerlProcessConnectionHandler. 

You lost it here, Chris. Input filters feed the protocol handler, not the 
other way around. It's actually very simple - w/o any filters the protocol 
handler read from the network and writes to the network. If there are 
filters they get a chance to modify the data that streams through them. 
sometimes a filter may decide to buffer the data and not let it through 
until later but filters and protocol handlers work independently: the 
protocol handlers simply ask the last input filter to give it data and 
that filter propogates that request to the next input filter and so on, 
till the network is reached, then the data flows back to through the whole 
chain of input filters till it reaches the protocol handler, each filter 
sees only a chunk of data at a time (normally not more than 8k). when the 
protocol handler wants to send data out, it just passes it to the first 
output filter, which then passes it to the next output filter, and so on, 
till the network is reached. again only a chunk of data is sent at a time.


> The
> PerlProcessConnectionHandler does the work of implementing the protocol;
> here state machine actions and database accesses are performed. The
> PerlOutputFilterHandler fills out bound bucket brigades with outbound server
> side protocol messages.
> 
> That is my best understanding of how a protocol implementation should be
> constructed... 
> 
> As the provided examples show, work can be done, for example, in the
> FilterHandlers.  What was the original intent? Is there ever a case where it
> would make sense to perform database queries/updates or hold state machine
> logic external to the data stream in a FilterHandler? 

Certainly. Take SSI for example, what if your files live in a database? In 
the case of PHP - they can run both as protocol handlers and filters, so 
for example you could have a mod_perl handler whose output is then 
processed by a php filter. As you can see you can mix and match different 
languages and re-use existing solutions, w/o reimplementing things in your 
favorite language.

> Making things work is not a problem. I can always make things work. What is
> the prevailing wisdom as to how things should work?

TIMTOWTD...

Perhaps you should explain what exact issue you are having with the 
protocol/filter handlers, so it'll be easier to explain :)


-- 
_____________________________________________________________
Stas Bekman mailto:stas@stason.org  http://stason.org/
MailChannels: Assured Messaging(TM) http://mailchannels.com/
The "Practical mod_perl" book       http://modperlbook.org/
http://perl.apache.org/ http://perl.org/ http://logilune.com/