Archive for the ‘Architecture’ Category

Dotnet Async Socket Server – 2.Architecture

April 14, 2010 4 comments


In this part, I will describe the basic concepts and architecture of our socket server we will implement.

Contents of this series


Static architecture


Let us to see the outlook of our Socket Server component.

  • SocketListener : Connection and messaging management with multiple clients
  • Simple Protocol Codec : By implementing the IProtocol interface, this support decoding(de-serialization) and encoding(serialization) services for the protocol.
  • Event Handler : Handling socket operations and messaging for the Simple Protocol.
  • Fake Service : This provides fake business service with input parameter as decoded object and return object for the encoding resource.
  • Management UI : Through UI Invoke helper class, this UI provides Winform display  and control of the server thread and information.

This server uses two external components.

  • System.Net.Sockets
  • Protobuf-Net : fast and well-designed protobuf implementation for .NET.

This system also will contains 3 communication components.

  • Silverlight Policy Server
  • Silverlight Client : uses the SocketClient class and provides XAML UIs.
  • Winform Client : uses the SocketClient class and provides Winform UIs.

And see some technical operations before the implementation.


Listener and Connection

Core classes should have a SocketAsyncEventArgs instances for high-performance async networking in the pure .NET framework.

  • The SocketClient : this use the connectAsync method of the SocketAsyncEventArgs to connect.
  • The SocketListener : this use only the acceptAsync method of the SocketAsyncEventArgs class and may have a list of the Connection object to store the accepted sessions.
  • The Connection class : main role of this is to listen and response for the messaging transactions of each socket session.

Let us to see the following conceptual diagram to understand the basic socket accepting process.

The <2.AcceptAsync> step should be started when the listener start and will be finished in the <4.Accept Completed> step. After creating a connection context, the second step should be restarted to listen another accept request from other socket clients.


SocketAsyncEventArgs pool manager and Buffer manager classes

Let us to see the SocketAsyncEventArgs pool manager class at this MSDN section.

“asynchronous socket operations are described by reusable SocketAsyncEventArgs objects allocated and maintained by the application. High-performance socket applications know best the amount of overlapped socket operations that must be sustained.”

Each connection should have a SocketAsyncEventArgs instance for the messaging operations (receive and send). So, the SocketAsyncEventArgs pool manager would provide the instance library of many SocketAsyncEventArgs instances.

We can also see the Buffer manager class on MSDN here.

“This class creates a single large buffer which can be divided up and assigned to SocketAsyncEventArgs objects for use with each socket I/O operation. This enables buffers to be easily reused and guards against fragmenting heap memory.”


When each connection is created by the Socket Listener, the listener assigns the total buffer from buffer manager to the connections’ MessageArgs with setting offset and count properties.