Hi Lee, On 3/30/07, Lee Carlson <[EMAIL PROTECTED]> wrote:
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?
Actually I was saying that we were able to get such precious information from *you*, a part of this community.
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.
You might be interested in joining the force to improve AsyncWeb? Dave is the leader of the probject, but it seems like his communication has blacked out temporarilly. (I am a little bit worried that I couldn't hear him for a couple months..) If you are interested, please refer to the following URL: http://asyncweb.safehaus.org/ The source code can be accessed from: https://svn.safehaus.org/repos/asyncweb/trunk/ Cheers, Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6
