In this post I will be talking about a very important aspect of the server called a session. The server will need this session to maintain client connections and process requests. When the server receives a login message the first step is to create a session object for this connection. This session object will store useful information like session ID, username, client connection, session lifetime objects, and communication details.

The session ID is a unique string assigned by the client. When the client sends a login message a GUID is created and preserved to identify the session. Every message sent by the client will contain this session ID. This guarantees the server can distinguish requests from each client that is connected.

Previously I explained that login will validate the username and password and we don’t want each request to trigger this. Once the login validation occurs the session is either destroyed because the user is not entitled to login or the session is preserved because it’s a valid user. The session has a username property that can be used to check entitlements on addition request messages received. I prefer not to load all the user entitlements at once because they can change while the user is connected and would be forced to destroy the session to re-load entitlements. So my session simply saves the username so entitlements can be checked on each request message.

The client has a connection to the server but this is a one way street that only allows messages to be sent from the client. We need to establish another connection from the server to the client to send our responses back. This means the client will be listening on a port for a connection just like the server does. Before the client sends a login message to it adds itself as a SoapReceiver on a port. The login message communicates what port the client is listening on. When the server receives this message it creates a session object that is responsible for creating a SoapSender object. The SoapSender connects back to the client on the port include in our login messages. We have just successfully opened two way communications between our client and server allowing messages to flow both ways. Yay!!!!

Let’s start talking a little about request messages. When the server receives a request message it find the correct command processor to handle it. The processor is given the request message and session objects to process. The processor can process the message and give no response, or can send a single response, or send many responses. Since the processor is given a session objects it’s easy to send a single response, but what if the processor needs to send response asynchronously to the client. In this case it can create an object that listens for the events and sends them using the session. We don’t want to store this object inside the processor because it only gets disposed on shutdown and this object should only exist while the client connection is open. The solution is to store it in the session that only exists while the client is connected. Good thing we implemented lifetime objects inside our session!!!

I designed my session to save Date/Time when last message was received. This will be used to verify the connection is active. The server will periodically iterate over all the sessions to make sure it has received a message in a specified interval. If the session becomes stale then it gets disposed. The guarantees that if the client crashes the session gets destroyed and objects don’t live longer then they’re supposed to.

*to be continued