mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Fisk"...@lastbamboo.org>
Subject Re: Best way to support both TCP/IP and HTTP?
Date Wed, 07 Nov 2007 16:26:26 GMT
There have been several messages on the list about an HTTP client
submission for MINA.  I'd just do a quick search.  I think it was from
one of the felix or apache directory authors.

I'm confused about your "TCP/IP & HTTP" points.  HTTP *can*
theoretically run over other transports, but it rarely happens in
practice.  p2p apps (like mine incidentally) with reliable UDP layers
sometimes do that sort of thing, but it's certainly not standard.
Generally when I hear "HTTP" I assume TCP.

Just use the MINA SocketConnector and SocketAcceptor, and you should
be all set.  AsyncWeb on the server side should be relatively solid,
and from what I've read the client side submission was relatively
complete.  If you need 100% compliance with RFC 2616, you'd certainly
have to do considerable work on both, but it doesn't sound like that's
what you're after.

-Adam


On Nov 7, 2007 9:57 AM, Jeff Mesnil <jmesnil@redhat.com> wrote:
> hi,
>
> I'm currently investigating MINA to use it as the transport layer
> between clients and servers for the next major version of JBoss
> Messaging (the JMS implementation of JBoss).[1][2]
>
> One of our requirements is to support both TCP/IP & HTTP (and their SSL
> flavours).
> The clients and servers must run on only one protocol at the time but it
> must be configurable by the user.
>
> I'm wondering what is the best way to achieve that.
>
> In my prototype, depending on a sys prop, the clients and server may
> have 2 different filter chains
>
> * in the TCP/IP case, both clients and server use a protocol codec
> filter to encode/decode our high level JMS messages directly into MINA
> IoBuffer
> * in the HTTP case, the client and server use an IoFilter to transform
> high level messages into HTTP requests/responses and a HTTP protocol
> codec filter.
>
> This means that we use only high level messages but we must provide for
> each type of message both a codec (for TCP/IP) and a filter (for HTTP).
>
> Does that sound sensible?
> I'm wondering if it would not be simpler to provide just one way to
> transform our messages into bytes and use them in both the codec
> & the filter. wdyt?
>
> I've also a concern with my handling of HTTP which is quite ugly.
> I've not found in either asyncweb (from the sandbox) or mina-codec-http
> a codec which supports the encoding/decoding of both HTTP request and
> response.
>
> This means that on the client, I use the codec provided by
> mina-codec-http to encode request / decode response while on the server
> I use the codec provided by asyncweb to decode request / encode response.
> And my HTTP filter is an headache: it transforms JMS messages into
> mina-codec-http's HttpRequestMessage when sending it.
> But it receives a asyncweb's DefaultHttpRequest on the server...
> It works but I find it quite weird to juggle between the 2 implementations.
>
> Stupid question: Have I missed the obvious? :) Is there a "full" http
> codec that I can use on both HTTP client & server?
> If no, is it planned for MINA 2.0 to provide such codec?
>
> Keep up the good work, MINA code is very cool to use,
> jeff
>
> [1] http://www.jboss.org/wiki/Wiki.jsp?page=JBossMessagingMinaIntegration
> [2] http://www.jboss.org/index.html?module=bb&op=viewtopic&t=122712
>
>
>
>
>
>
>
>
>



-- 
http://www.littleshoot.org
Open Source, Open Standards, Open Data

Mime
View raw message