Apache Mina Development Manual IV

Apache Mina Development Manual IV

Apache Mina Development Manual IV

1. Main steps of Mina Development

1. Create a class that implements the IoService Interface

The IoService interface has two subinterfaces:
1) IoAcceptor interface for Servers
2) IoConnection interface for the client

The IoService interface is designed to provide services. There are several default implementations:
NioDatagramAcceptor and niodatagramconne
NioSocketAcceptor and NioSocketConnector
VmPipeAcceptor and VmPipeConnector
ProxyConnector

2. Set a filter. If a custom filter is required, the IoFilter interface must be implemented.
IoFilter is used to create a layer of filters, which are the same as the filters in Servlet specifications.
The IoFilter interface has many default implementations, some of which are for internal use only, some for users, and the filter sequence can affect program running. Common Implementation classes include:
1) ExecutorFilter: any operation after this filter will work on this Executor
2) LoggingFilter: log operation filter used to record logs
3) ProtocolCodecFilter: separates the protocol layer from the business layer.
4) ProxyFilter: A proxy filter that intercepts requests or responses and forwards them to the proxy.
5) SslFilter: used for SSL communication

3. Create a processing class that implements the IoHandler interface to process events.
Handle business logic, especially the IoSession interface.

4. Bind a port to IoService.

Ii. Mina custom protocol

Example in Mina:
Org. apache. mina. example. chat: supports Spring, Jmx, and custom protocols.
Org. apache. mina. example. imagine: supports Jmx and custom protocols.
Org. apache. mina. example. sumup: supports custom protocols.
Org. apache. mina. example. tapedeck: state machine demonstration, custom protocol

Iii. Protocol Decoder

The Protocol decoder depends on the ProtocolDecoder interface:

Public interface ProtocolDecoder {// decodes the content of the binary or specific protocol into the void decode (IoSession session, IoBuffer in, ProtocolDecoderOutput) of the advanced message ); // call the void finishDecode (IoSession session, ProtocolDecoderOutput out) method when the specified session is closed; // release all resources related to this decoder void dispose (IoSession session) throws Exception ;}

For Asynchronous reasons, the content accepted by the passed IoBuffer is not completely determined, that is, the content stored in IoBuffer after a receive is not necessarily a complete protocol, there may be multiple incomplete protocols, or even a complete agreement, which is not certain.
Based on the above situation, the actual development is generally to implement the CumulativeProtocolDecoder class, the role of this abstract class is to provide some help for the parsing protocol, this abstract class implements the decode interface in the ProtocolDecoder interface, and Abstract A doDecode method. The doDecode method requires that if a protocol can be parsed, the Protocol is parsed and put into the ProtocolDecoderOutput class, and true is returned. Otherwise, false is returned directly, and POS needs to be rolled back manually.

The Protocol decoder can work in two ways:
1) completely handled by doDecode
2) The logic is handled by the doDecode method, and the IoBuffer is semi-automated.

Iv. Protocol Encoder

The Protocol encoder depends on the ProtocolEncoder interface.

Public interface ProtocolEncoder {// encode an advanced message Object into a binary or specific protocol data void encode (IoSession session, Object message, ProtocolEncoderOutput out ); // release all resources related to this Protocol encoder void dispose (IoSession session) throws Exception ;}

The Protocol encoder can be fully automated, because it can write the required content into IoBuffer at a time and hand it over to ProtocolEncoderOutput. the backend will write the required content as much as possible based on the buffer size, the entire protocol to be sent in ProtocolEncoderOutput is sent.