The IoSession is at the heart of Mina.NET: every time a client connects to the server, a new session is created, and will be kept in memory until the client is disconnected.

A session is used to store persistent informations about the connection, plus any kind of information the server might need to use during the request processing, and eventually during the whole session life.

Session state

A session has a state, which will evolve during time.
  • Connected: the session has been created and is available
  • Idle: the session hasn't processed any request for at least a period of time (this period is configurable)
    • Idle for read: no read has actually been made for a period of time
    • Idle for write: no write has actually been made for a period of time
    • Idle for both: no read nor write for a period of time
  • Closing: the session is being closed (the remaining messages are being flushed, cleaning up is not terminated)
  • Closed: The session is now closed, nothing else can be done to revive it.

The following state diagram exposes all the possible states and transitions:

(The image is from Apache MINA)


Many different parameters can be set for a specific session:
  • Read buffer size
  • Idle time
  • Write timeout
  • other configuration, depending on the transport type used (see Transports)

Managing user-defined attributes

It might be necessary to store some data which may be used later. This is done using the dedicated data structure associated with each session. This is a key-value association, which can store any type of data the developer might want to keep remanent.

For instance, if you want to track the number of request a user has sent since the session has been created, it's easy to store it into this map: just create a key that will be associated with this value.

int counterValue = session.GetAttribute<Int32>("counter");
session.SetAttribute("counter", counterValue + 1);

We have a way to handle stored Attributes into the session: an Attribute is a key/value pair, which can be added, removed and read from the session's container.

This container is created automatically when the session is created, and will be disposed when the session is terminated.

Defining the container

As we said, this container is a key/value container, which default to a Dictionary, but it's also possible to define another data structure if one want to handle long lived data, or to avoid storing all those data in memory if they are large: we can implement an interface and a factory that will be used to create this container when the session is created.

This snippet of code shows how the container is created during the session initialization:

protected void InitSession<TFuture>(IoSession session, TFuture future, Action<IoSession, TFuture> initializeSession) where TFuture : IoFuture
  AbstractIoSession s = session as AbstractIoSession;
  s.AttributeMap = s.Service.SessionDataStructureFactory.GetAttributeMap(session);

and here is the factory interface we can implement if we want to define another kind of container:

public interface IoSessionDataStructureFactory
  IoSessionAttributeMap GetAttributeMap(IoSession session);

Filter chain

Each session is associated with a chain of filters, which will be processed when an incoming request or an outgoing message is received or emitted. Those filters are specific for each session individually, even if most of the cases, we will use the very same chain of filters for all the existing sessions. However, it's possible to dynamically modify the chain for a single session, for instance by adding a Logger Filter in the chain for a specific session.


Each session also keep a track of records about what has been done for the session:
  • Number of bytes received/sent
  • Number of messages received/sent
  • Idle status
  • Throughput


To write a message to a session, simply call the Write() method:

session.Write( <your message> );

Last edited Apr 14, 2014 at 8:01 AM by longshine, version 2