Hi
Rocco Caputo wrote:
It's unfair to ask for a comprehensive ("avoid as many dead ends as possible") analysis of a complex system that is only described in basic terms. The best anyone can do under these circumstances is provide generic advice. Specific advice will invariably miss some hitherto unexplained detail that invalidates the analyst's assumptions and sets them back. Repeat for every mis- or insufficiently understood detail, and the frustration (and time cost) mount. One set of dead ends has been replaced with another.
Sure - agree completely. For that very reason I'm just trying to get the skeleton roughly right first
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?)
- 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)
- 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?
Thanks Ed W
