Hi Jeremy, You got it right. Implementing a protocol codec is a correct solution, and it will take some extra work. However, it might not be a lot of work depending on how the message is framed. You could let me know what the message looks like then I could suggest you some codec classes you can extend. Typically, people find CumulativeProtocolDecoder very useful. You could also start from our protocol codec tutorial.
The advantage of MINA is it scales up better than plain blocking-I/O based server. Typically, you will see your server suffer from contention when the number of clients becomes greater than 1000. Moreover, if your server has to maintain hundred thousands of connections with low traffic, blocking I/O doesn't work very well. Besides performance advantage, MINA has nice integration with JMX and IoC frameworks. You can monitor overall traffic, search connections which meet a certain criteria using a query language, and manipulate each connection in runtime. From the application design standpoint, 1) MINA provides explicit separation between I/O service, protocol codec and business logic, so your server will be very flexible and easy to understand. 2) MINA hides the underlying transport, so you can switch from one transport to the other. For example, serial port communication to NIO-based TCP/IP and NIO-based TCP/IP to APR-based TCP/IP. In the future, MINA team will add more transports, and then you can move to the new transport which might performs or fits better for your needs (e.g. SCTP and Infiniband). If you don't need a flexible and extensible server which scales very well and provides nice management feature, then you can just stick to your own server implementation which also should be very easy to write. It's up to you anyways. :) Jeremy Haile wrote: > Where would I get the IoBuffer object from? In > IoHandler.messageReceived()? In that case, wouldn't the IoBuffer only > represent one chunk of the data that is being streamed? > > In my case, I want to read from the InputStream constantly. I guess an > alternative would be to implement my own ProtocolDecoder and have it > chunk things such that I could feed one chunked inputstream at a time to > the third party library, but this seems like a lot of work given the > alternative of just opening a socket and passing the inputstream to the > 3rd party library. > > So, let's say I implemented a ProtocolDecoder that chunks the IoBuffer > into reasonable pieces that could be handled independently by the 3rd > party library. Why go to all of that extra effort when I can just open > a socket and pass it to the 3rd party library? What is MINA offering me > in this scenario? > > Or am I missing the suggestion completely? > > On Apr 3, 2008, at 9:50 AM, "이희승 (Trustin Lee) <[EMAIL PROTECTED]> > wrote: > >> Hi Jeremy, >> >> Calling IoBuffer.asInputStream() or IoBuffer.asOutputStream() could >> address your issue. Could you give them a try? >> >> HTH, >> >> Jeremy Haile wrote: >>> I'm using MINA as a server to process client connections. However, my >>> application also needs to make a client connection to a server and feed >>> the retrieved data to a 3rd party library. The client connection will >>> be maintained 24 hours a day, so it is important that it can reconnect >>> automatically in case of network failure. >>> >>> The 3rd party library requires an InputStream to process data. I >>> originally attempted to use the StreamIoHandler with a SocketConnector >>> but ran into problems and found archived messages recommending not to >>> use this handler. >>> >>> Given that the 3rd party library requires an InputStream, is MINA the >>> appropriate choice? There is only one client connection, so non-blocking >>> vs blocking I/O really isn't an issue. Should I simply use a socket? >>> If not, what does MINA really offer me over a plain socket connection in >>> this case? >>> >>> The only thing I can think of is exception handling event callbacks >>> which could assist with automatic reconnections. Of course, with the >>> socket I can just wrap my InputStream processing and catch all >>> IOExceptions - then attempt to reconnect after a short delay. >>> >>> Any advice? >>> >>> Thanks, >>> Jeremy Haile >> >> -- >> Trustin Lee - Principal Software Engineer, JBoss, Red Hat >> -- >> what we call human nature is actually human habit >> -- >> http://gleamynode.net/ >> > -- Trustin Lee - Principal Software Engineer, JBoss, Red Hat -- what we call human nature is actually human habit -- http://gleamynode.net/
signature.asc
Description: OpenPGP digital signature
