Home > Architecture, Networking, Silverlight > Dotnet Async Socket Server – 2.Architecture

Dotnet Async Socket Server – 2.Architecture

 

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

Contents of this series

 

Static architecture

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.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: