Re: Architecture advice requested

I'm sorry that I missed the point completely.   I'll avoid commenting
in the future.
good luck with the project.

On Mon, May 25, 2009 at 2:44 AM, Ed W <[email protected]> wrote:
> chris fedde wrote:
>>
>> My second reaction is to wonder if you can do better in perl than a
>> demand dial PPP link would provide.
>>
>
> ?  You need both.  At $1.50/min you want this dialup link only up when you
> need it
>
> Right now since most users are on windows we just show them the normal
> windows dialup feature and they dial when they need to do stuf
>
>> My third reaction is to wonder if it is not better to use something
>> like UUCP and batch load across the link.
>>
>
> Hardly.  Doing the algorithm described you are pretty close to a solid block
> of data moving in both directions simultaneously, including compression and
> management of tcp packet size.  So the efficiency approaches that of UUCP +
> intensive compression, but both ends talk a standard protocol
>
>> Interactive protocols like POP, IMAP, and HTTP are going to be very
>> hard to use over such a slow high latency link.
>>
>
> ?? That's why this project exists in the first place?
> Just to be clear: this exists already, I'm doing a structural enhancement.
>  Current code is really only a few hundred lines at it's core, runs to a
> couple of thousand once you handle all the protocol parsing, gui and other
> special cases
>
> Download a trial from http://www.mailasail.com - the client is packed as an
> EXE, but I doubt that will stop an enterprising soul who wants to see how it
> works...
>
>> If your goal is just email then I'd recommend setting up a local MTA
>> and configure it to use ETRN to collect mail queued at an MTA on an
>> internet connected host.
>
> OK, so that's only about 5x slower than my proposed solution.  No
> compression and large latency due to each SMTP command being sent one by
> one.  Don't forget that tcp slow start will also hurt you.
>
> I think my suggestion is much better...
>
>>  You'll also want very good spam filtering
>> on the connected side to avoid paying for too much spam.
>>
>
> Sure - done.
>
> Also we do a huge amount more like killing redundant email headers,
> eliminating extra HTML sections and optionally blackberry like attachment
> mangling into text.
>
>
> What I am really looking for are suggestions on how to structure a small
> proxy application which will really stretch the POE architecture because the
> outer layers are quite integrated with the inner layers
>
> The inner side of the app is presumably just going to be several wheels
> proxying to each other, eg pop server is the in side, talking to a pop
> client wheel which then goes back out to the network and the real server.
>  However, given that I want to compress this output and multiplex it, is it
> best to call that an output filter?  How might I signal to the output filter
> that I want the compression buffered at this point in the stream?  How might
> I indicate that this stream should get priority over this other stream?)
>
> What about the receiving end which gets a compressed stream packing several
> protocols.  There will need to be a bit of logic to handle corruption,
> invalid input, etc.  Then it needs to unpack this into several protocol
> streams and feed them to several protocol parsers.  Does that sound like an
> input filter or is it a wheel because there might be some state information
> (several packets to join, etc)
>
> Any thoughts?  Any demo apps which show parts of this functionality?
>
> Thanks
>
> Ed W
>