Hi Trustin, and thanks for all the time, patience great code you have
contributed.  When you say "where could we get such precious
information?" do you mean where could you get the details/code for the
HttpChannal?  

I'd be glad to contribute some code if it would be useful to someone or
if it may be desirable to include it in mina, but it will take a fair
amount of refactoring to make it work with Mina.  I started out using
Mina, but while designing the http push/pull virtual channel, I found
that the architecture required mina-like features such as filters, event
handlers, but I needed those features to exist at a layer above the
socket session, so I basically wound up creating a whole new framework
which now only uses the SocketIoProcessor and a couple other classes
from Mina, but they too have been modified a fair amount. All the work
is now done in the Channel layer so that socket disconnections don't
disrupt the message queue, filter state, etc., so messages can be
retried on failure, responses handled, and the application won't know
the difference. SocketSession is used for point A to B connectivity, and
events propogate to the channel layer, then finally to the application
as necessary.

The overall design is similiar to mina, as the Mina design is elegant
and was my inspiration.  This framework (oh no, I just realized I used
the 'F' word) has compression, encryption, write queue control to
prevent OOM error (the caller simply blocks when the queue is full),
built in message retries if failure, message handlers, message responses
using a "ResponseFuture.getResult()" which is returned from a
ChannelSession.write() call, etc..  It's still in progress but is 90%
complete - I'm just working on the UDP channels now which I'm using to
do firewall hole punching for P2P use. TCP hole punching is already
built in. After that I have to finish the keep-alive functionality.  All
the complexity is kept internal so my application just has to say "send
this stuff to there" and the client-server-peer framework peices
automatically negotiate proper ways to route the messages around
firewalls, through http proxy servers, or direct p2p with the use of the
coordinating server. Been working on it for about 6 months.

The compression filter has a neat little feature in that it has a simple
automatic mode which checks the obtained compression from messages and
will automatically enable/disable compression on the fly based on the
configured minimum compression percent, so if you set it to 40 percent,
it will back off if it can't obtain that. For single messages it's
useless, but when transferring a file it quickly notices if good
compression can be obtained and will either continue to compress or will
back off exponentially and not waist CPU power do it if the data doesn't
compress well anyway. This filter would port to mina just fine I think.

r/ Lee

On Thu, 29 Mar 2007 10:32:16 +0900, "Trustin Lee" <[EMAIL PROTECTED]>
said:
> Hi Lee,
> 
> On 3/28/07, Lee Carlson <[EMAIL PROTECTED]> wrote:
> > Yes, the whole Push/Pull approach is complex and if it can be avoided,
> > lucky you.  As any programmer can attest to, it's always nice to
> > discover the pittfalls of an approach to a problem BEFORE spending a
> > couple of weeks persuing the solution, only to learn something which
> > destroys that beautiful solution you were working on.   I felt it my
> > obligation to share some of my experiences if there was any chance of it
> > saving you or someone else a lot of waisted time.  Good luck!
> 
> Thank you so much for sharing your experience!  Where could we get
> such precious information?
> 
> Regards,
> Trustin
> -- 
> what we call human nature is actually human habit
> --
> http://gleamynode.net/
> --
> PGP Key ID: 0x0255ECA6

Reply via email to