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 >
