Re: Architecture advice requested

On May 29, 2009, at 04:48, Ed W wrote:
>
> Rocco Caputo wrote:
>>
>> The best way to break an application into POE entities is not to.   
>> Decompose the application into entities and relationships that make  
>> sense for the application.  Determine the requirements first, then  
>> apply POE to fulfill them.
>
> OK, to be specific, the heart of it is a proxy server, which seems  
> to be fulfilled by using protocol X client wheel talking to protocol  
> X server wheel?  The bits I guess I am most interested in are:
>
> - How I might architect the POP server client to be one step removed  
> from the socket and have the following pipeline attached to the  
> socket:   data_in -> decompress -> parse input data into separate  
> protocols and feed to correct wheel.  Is this another wheel, or done  
> as a filter? (or something else?)

I might implement this in application code until I knew the  
requirements and constraints on the data_in -> decompress -> parse  
flow.  As those emerged (or were specified), I might refactor the  
generic transformative bits into their own modules.  The most  
significant trade-off seems to be whether reusability or throughput is  
more important.  If reusability: I would refactor the transformative  
code into POE::Filter, POE::Driver and/or POE::Wheel namespaces.  If  
throughput, I would evaluate whether custom object APIs fit the  
application better.

> - Same for the output.  ie taking the output of multiple wheels,  
> compressing the output and then blocking it into a simple protocol  
> to multiplex over a single TCP connection (just data packet with a  
> header on it)

Funneling would be done by a component (aka "a module that uses  
POE").  There seems to be a lot of decision logic and the possibility  
that the funnel will respond to individual clients.  Something higher  
level must be responsible for the side effects since POE::Filter and  
POE::Wheel::ReadWrite are strictly transformative.

> - The main reason for looking at POE is that while it's mostly a  
> pipeline, occasionally one distinct bit of the app needs to talk to  
> another distinct bit, eg some remote end hangs up suddenly, the  
> client end may not be expecting this as part of it's normal protocol  
> and we need to wake it up and force it to terminate the other side  
> of the proxy.  Any special features of POE which would be especially  
> helpful here?

It sounds like you want the client and server sides of the proxy to be  
loosely coupled.  For instance, the remote end may hang up suddenly at  
the end of a message, but the local end may still be receiving.  You  
might want to wait for the local end to finish before shutting down  
the connection.

POE can help accomplish this by making it easier to decouple the  
client and server sides of the proxy.  The proxy behavior is then  
goverend by the message protocol you define between the client and  
server, rather than by the particular protocols on either end.

Recently I've seen POE used to proxy between stateless HTTP and a  
stateful game.  The idea seems similar.  It allows an HTTP client to  
come and go, but it keeps the game connected.  It adapts the two by  
tracking the game's state in the proxy, then updating the user when  
they refresh the page.

POE doesn't have a component for mapping client and server sides of  
proxies.  If you write one, I hope you can release it.

-- 
Rocco Caputo - [email protected]