This tutorial tries to explain why and how to use a
Why use a
- TCP guarantess delivery of all packets in the correct order.
But there is no guarantee that one write operation on the sender-side will result in one read event on the receiving side.
see http://en.wikipedia.org/wiki/IPv4#Fragmentation_and_reassembly and http://en.wikipedia.org/wiki/Nagle%27s_algorithm
In MINA terminology: without a ProtocolCodecFilter one call of
IoSession.write(Object message)by the sender can result in multiple
messageReceived(IoSession session, Object message)events on the receiver; and multiple calls of
IoSession.write(Object message)can lead to a single messageReceived event. You might not encounter this behavior when client and server are running on the same host (or an a local network) but your applications should be able to cope with this.
- Most network applications need a way to find out where the current message ends and where the next message starts.
- You could implement all this logic in your IoHandler, but adding a
ProtocolCodecFilterwill make your code much cleaner and easier to maintain.
It allows you to separate your protocol logic from your business logic (
Your application is basically just receiving a bunch of bytes and you need to convert these bytes into messages (higher level objects).
There are three common techniques for splitting the stream of bytes into messages:
- use fixed length messages
- use a fixed length header that indicates the length of the body
- using a delimiter; for example many text-based protocols append a newline (or CR LF pair) after every message (http://www.faqs.org/rfcs/rfc977.html)
In this tutorial we will use the first and second method since they are definitely easier to implement. Afterwards we will look at using a delimiter.
We will develop a (pretty useless) graphical chargen server to illustrate how to implement your own protocol codec (
The protocol is really simple. This is the layout of a request message:
- width: the width of the requested image (an integer in network byte-order)
- height: the height of the requested image (an integer in network byte-order)
- numchars: the number of chars to generate (an integer in network byte-order)
The server responds with two images of the requested dimensions, with the requested number of characters painted on it.
This is the layout of a response message:
variable length body
variable length body
- length1: the number of bytes used by image1
- image1: an image in PNG format
- length2: the number of bytes used by image2
- image2: an image in PNG format
Overview of the classes we need for encoding and decoding requests and responses:
ImageRequest: a simple POJO representing a request to our ImageServer.
ImageRequestEncoder: encodes ImageRequest objects into protocol-specific data (used by the client)
ImageRequestDecoder: decodes protocol-specific data into ImageRequest objects (used by the server)
ImageResponse: a simple POJO representing a response from our ImageServer.
ImageResponseEncoder: used by the server for encoding ImageResponse objects
ImageResponseDecoder: used by the client for decoding ImageResponse objects
ImageCodecFactory: this class creates the necesarry encoders and decoders
Encoding is usually simpler than decoding, so let's start with the
- MINA will call the encode function for all messages in the IoSession's write queue. Since our client will only write
ImageRequestobjects, we can safely cast message to
- We allocate a new
IoBufferfrom the heap. It's best to avoid using direct buffers, since generally heap buffers perform better.
- You do not have to release the buffer, MINA will do it for you, see http://mina.apache.org/report/trunk/apidocs/org/apache/mina/common/IoBuffer.html
- In the
dispose()method you should release all resources acquired during encoding for the specified session. If there is nothing to dispose you could let your encoder inherit from
Now let's have a look at the decoder. The
CumulativeProtocolDecoder is a great help for writing your own decoder: it will buffer all incoming data until your decoder decides it can do something with it.
In this case the message has a fixed size, so it's easiest to wait until all data is available:
- everytime a complete message is decoded, you should write it to the
ProtocolDecoderOutput; these messages will travel along the filter-chain and eventually arrive in your
- you are not responsible for releasing the
- when there is not enough data available to decode a message, just return false
The response is also a very simple POJO:
Encoding the response is also trivial:
- when it is impossible to calculate the length of the IoBuffer beforehand, you can use an auto-expanding buffer by calling
Now let's have a look at decoding the response:
- We store the state of the decoding process in a session attribute. It would also be possible to store this state in the Decoder object itself but this has several disadvantages:
- every IoSession would need its own Decoder instance
- MINA ensures that there will never be more than one thread simultaneously executing the decode() function for the same IoSession, but it does not guarantee that it will always be the same thread. Suppose the first piece of data is handled by thread-1 who decides it cannot yet decode, when the next piece of data arrives, it could be handled by another thread. To avoid visibility problems, you must properly synchronize access to this decoder state (IoSession attributes are stored in a
ConcurrentHashMap, so they are automatically visible to other threads).
- a discussion on the mailing list has lead to this conclusion: choosing between storing state in the IoSession or in the Decoder instance itself is more a matter of taste. To ensure that no two threads will run the decode method for the same IoSession, MINA needs to do some form of synchronization => this synchronization will also ensure you can't have the visibility problem described above.
(Thanks to Adam Fisk for pointing this out)
IoBuffer.prefixedDataAvailable()is very convenient when your protocol uses a length-prefix; it supports a prefix of 1, 2 or 4 bytes.
- don't forget to reset the decoder state when you've decoded a response (removing the session attribute is another way to do it)
If the response would consist of a single image, we would not need to store decoder state:
Now let's glue it all together:
- for every new session, MINA will ask the
ImageCodecFactoryfor an encoder and a decoder.
- since our encoders and decoders store no conversational state, it is safe to let all sessions share a single instance.
This is how the server would use the
Usage by the client is identical:
For completeness, I will add the code for the server-side IoHandler:
The complete code for this tutorial (basic server + Swing client) can be found here.
There is a lot more to tell about encoding and decoding. But I hope this tutorial already gets you started.
I will try to add something about the
DemuxingProtocolCodecFactory in the near future.
And then we will also have a look at how to use a delimiter instead of a length prefix.