I know, it's a daunting task to design, develop and implement a robust managed network library,  can be totally mind boggling and may cause loss of hair , but when you really need something specific to suits your different application needs or if you think you can do better implementation than using the tools that are already available,  most of the time you force yourself to code from scratch or at least you try to roll your own implementation.

Of course, I know the notion of  'reinventing the wheel' and I'm also aware that there are lots of great network library project already been created out there and ready to use, but most of them I've seen so far, only offers a single network implementation or using only a specific .NET network technology features and you feel like your still working on the socket level. This is one of the main reason I wanted to try and create my own network library to find out which network technology and socket processing scheme will be best suited to different types of multiuser application needs. What I really wanted to do is to develop a network library which is interchangeable with ease of use and to be able to test other networking technology and different kinds of socket processing scheme in the simplest form.

A configurable network computing implementation seems to be a good idea to start designing a network library, and here's my implementation on how I configure my server that uses different kinds of enumerated network technology and socket processing scheme. The port  is the only one that needs to be set manually, other implementations are all enumerated to lessen the hardcoding hassle, whether I wanted to use IPv4 or IPv6, UDP or TCP, .NetClients or  raw Socket Berkely, IPv4-Broadcasting or IPv4/IPv6-Multicasting and other network settings. The most interesting part I've done so far, I can choose what type of socket processing scheme for a specific application requirements or game type by selecting socket cores processing mode to work Synchronously, Asynchronously,  Per player thread, Per player asynchronous mode or a single thread for socket selecting or polling mode.

 
Before starting listening for connecting clients, first I need to set  my network setting  parameter  when creating  new lobby server instance and sets my server configuration parameter when starting lobby service, that's it and I'm ready to start listening to any incomming client connection.

 

// Using  ZNC = ZGDK.Net.Core;
// Using  ZNE  = ZGDK.Net.Enum;
// Using  ZNH  = ZGDK.Net.Helper;

 

//!>>> 2). Creating new server instance with prefered network settings.
//
ZNC.LobbyServer _Server = new ZNC.LobbyServer( m_NetSetting );

 

 

//!>> > 3).  Preparing server configuration
//

ZNC.ServerConfig m_ServerConfig = new ZNC.ServerConfig();  m_ServerConfig.SetDefault();
// 
m_ServerConfig.ApplicationName  = "Mech Rider-Z Alpha Rel. 0.002";
m_ServerConfig.LobbyName         = "Dexter Channel";
//
m_ServerConfig.EnableIPv6          = false;
m_ServerConfig.Connection          = ZNE.ConnectionType.Internet;
m_ServerConfig.Protocol              = ZNE.Protocol.UDP;
m_ServerConfig.SocketType         = ZNE.SocketType.Berkely; 
m_ServerConfig.IPAddress           = ZNH.GetMachineLocalIP(  ZNE.IPVerion.IPv4  );  
m_ServerConfig.ServerPort          = 60055;

//
m_ServerConfig.CasterPort           = 60057;

m_ServerConfig.CasterType          = ZNE.CasterType.Multicast;
m_ServerConfig.CasterGroup        = ZNE.CasterGroup.IPv4_WORKGROUP;
//
m_ServerConfig.AcceptorMode      = ZNE.SAcceptorMode.UsingUDP;
m_ServerConfig.ReceiverMode      = ZNE.SReceiverMode.UdpThreadOnly;
m_ServerConfig.SenderMode        = ZNE.SenderMode.AsyncIOCP;

//!>>> 4). Start lobby server service with  prefered server configuration.
//
 _Server.StartLobbyService( m_ServerConfig );

//!>>> 5).  Start accepting new client connection.
//
_Server.AcceptorMngr.StartAccepting();

 

S E R V E R   C O N F I G U R A T I O N :  

m_ServerConfig.ApplicationName  = "Mech Rider-Z Alpha Rel. 0.002";

Why I need to specify the name of the application in server configuration? though, this is irrelevant when using connection type over the internet, but working on local area network the client needs to specify the game or application name when searching for available games accross the local subnet.

 

ZNC.LocalGames[] m_LocalGames = ZNH.SearchLocalGames(  "Mech Rider-Z Alpha Rel. 0.002",  1000  );

 

The client should retrieves all available machine's hosting "Mech Rider-Z Alpha Rel. 0.002" game as an example on the local sub-net.  I will ellaborate more on this later on when I tackle my implementation for Boadcasting and Multicasting messages accross the local sub-net and how game sessions can be automatically discover.

 

 
Lobby name

 m_ServerConfig.LobbyName = "Dexter Channel";
 

Whether hosting a game over the internet or on the local sub-net, assigning a lobby name is one way to identify the host machine, for instance multiple machine created a game session, the client looking for available games, should retrieve all created game sessions along with lobby name for host distinction, though, from using over the internet I intend to use Lobby name as a Server channel description hosting the same game over the internet using different server machine.

 

 

 

 

 

 

The two well known Network Protocol in  computer networking are  Transport Connection Protocol (TCP) and the Unrealiable Datagram Protocol... Oppps! my bad, the correct one is User Datagram Protocol (UDP). TCP and UPD are the dominant protocols lurking over the internet and to most networking environments. TCP and UDP should be supported in my implementation, although  some  may say that if you can implement a robust reliable UDP messaging scheme there's no need for a TCP implementation, because it will just overkill the design, but never the less I'm still supporting the use of TCP protocol. The .NET framework Remoting features in my design plan will be drop due to my own implementation on sending and updating of on object remotely.

 

m_ServerConfig.Protocol = ZNE.Protocol.UDP;  

                                                            TCP

 
 

 
The .NET framework offers UdpClient, TcpClient, TcpListener and Raw Socket Berkely for it's socket interface, but which one is better and more effecient? well, the best thing to do is to run the the application and choose which socket type works best for your application. Luckily, both socket interface are supported in my implementation.

m_ServerConfig.SocketType = ZNE.SocketType.Berkely; 

                                                                     NetClient

 

 

 
Exchanging messages needs to agree with the same protocol, whether you are using a TCP or UDP, each message has to contain the address of its destination just like a telegrams. Shame on me, if I still need to manually hardcoded the machine's local IP address everytime I transfer and use different station to run the server application, creating a simple method that returns machine's local IP address is very handy.

 

m_ServerConfig.IPAddress  = ZNH.GetMachineLocalIP(  ZNE.IPVerion.IPv4 );  

 

 

How many ports should I need to open on the server end? In my implementation whenever the announcer is enable which will only works on the local subnet but not over the internet, a new UDP socket and port will be open and created whether the core socket is using TCP or UDP protocol.  The core socket using UDP or TCP,  a  single server listener port is only needed.

 

The option for sending messages to all other machines across the local sub-net or group of host at the same time should not be taken for granted, implementing broadcasting or multicasting features are also included in my implementation, which can surely save a lot of bandwidht, more details on this when I discuss about the role of  caster manager and it's  functionality in my implementation. The following are the options to configure broadcast messaging.

m_ServerConfig.CasterPort    = 60057;

 

m_ServerConfig.CasterType   = ZNE.CasterType.Multicast;  

                                                                      Broadcast;

 

m_ServerConfig.CasterGroup = ZNE.CasterGroup.IPv4_WORKGROUP;
       

Here's the complete enumeration for caster group address :

 

BROADCAST,
IPv4_WORKGROUP,IPv4_ROUTER, IPv4_OSPF, IPv4_OSPF_ROUTER, IPv4_RIPV2, IPv4_EIGRP, IPv4_VRRP,IPv4_IGMP,
IPv6_WORKGROUPSEGMENT, IPv6_WORKGROUPSITE, IPv6_ROUTER, IPv6_DHCP, IPv6_NIS

 

  
Socket processing scheme is the most important aspect in network implementation IMO. I will tackle this part on my next post including some diagram for each processing scheme that can that can be acquire by just changing the socket core processing mode.

 

m_ServerConfig.AcceptorMode  = ZNE.SAcceptorMode.Thread;  

                                                                                 Asynchronous;
                                                                                 UsingUDP;                                                                              

m_ServerConfig.ReceiverMode   = ZNE.SReceiverMode.TcpThreadPollOnly;
                                                                                 TcpThreadPollIOCP

                                                                                 TcpThreadSelectOnly

                                                                                 TcpRecusrsiveAsyncIOCPPerPlayer

                                                                                 UdpThreadOnly
                                                                                 UdpThreadIOCP

                                                                                 UdpRecursiveAsyncIOCP

 

 

m_ServerConfig.SenderMode     = ZNE.SenderMode.Synchronous; 

                                                                              Asynchronous;

 

LOBBY SERVER NETWORK SETTING:

...

Basically, this is just the tip of the iceberg from the whole network implementation and  I can't wait to discuss the full functionality on the server end like the ff server managers :  _Server.AcceptorMngr,  _Server.SenderMngr,  _Server.ReceiverMngr,  _Server.MessageMngr,  _Server.CasterMngr, _Server.LobbyMngr, _Server.GameMngr, _Server.SessionMngr, Frequency tuning,  Error handling and Buffer overrun monitoring.