| Profilo di DexterC# Network library proje...FotoBlogElenchi | Guida |
C# Network library projectLeTz RoCk N' CoDe! with .Net and Network technology. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Game server design & architecture blog list
Cool networking related links
|
22 novembre NAT Traversal in .NET Framework Version 4I've just installed MSVS 2010 Beta 2 and this is just one of the surprise thats interest me on what's new on .NET Framework Version 4 particularly on networking. Taken from MSDN: NAT Traversal using IPv6 and Teredo Enhancements were made that provide support for Network Address Translation (NAT) traversal. These changes are designed for use with IPv6 and Teredo, but they are also applicable to other IP tunneling technologies. These enhancements affect classes in the System.Net and related namespaces. These changes can affect client and server applications that plan to use IP tunneling technologies. The changes to support NAT traversal are available only for applications using .NET Framework version 4. These features are not available on earlier versions of the .NET Framework. Overview
The Internet Protocol version 4 (IPv4) defined an IPv4 address as 32 bits long. As a result, IPv4 supports approximately 4 billion unique IP addresses (2^32). As the number of computers and network devices on the Internet expanded in the 1990s, the limits of the IPv4 address space became apparent. One of several techniques used to extend the lifetime of IPv4 has been to deploy NAT to allow a single unique public IP address to represent a large number of private IP addresses (private Intranet). The private IP addresses behind the NAT device share the single public IPv4 address. The NAT device may be a dedicated hardware device (an inexpensive Wireless Access Point and router, for example) or a computer running a service to provide NAT. A device or service for this public IP address translates IP network packets between the public Internet and the private Intranet. This scheme works well for client applications running on the private Intranet that send requests to other IP addresses (usually servers) on the Internet. The NAT device or server can keep a mapping of client requests so when a response is returned it knows where to send the response. But this scheme poses problems for applications running in the private Intranet behind the NAT device that want to provide services, listen for packets, and respond. This is particularly the case for peer-to-peer applications. The IPv6 protocol defined an IPv4 address as 128 bits long. As a result, IPv6 supports very a large IP address space of 3.2 x 10^38 unique addresses (2^128). With an address space of this size, it is possible for every device connected to the Internet to be given a unique address. But there are problems. Much of the world is still using only IPv4. In particular, many of the existing routers and wireless access points used by small companies, organizations, and households do not support IPv6. Also some Internet service providers that serve these customers either do not support or have not configured support for IPv6. Several IPv6 transition technologies have been developed to tunnel IPv6 addresses in an IPv4 packet. These technologies include 6to4, ISATAP, and Teredo tunnels that provide address assignment and host-to-host automatic tunneling for unicast IPv6 traffic when IPv6 hosts must traverse IP4 networks to reach other IPv6 networks. IPv6 packets are sent tunneled as IPv4 packets. Several tunneling techniques are being used that allow NAT traversal for IPv6 addresses through a NAT device. Teredo is one of the IPv6 transition technologies which brings IPv6 connectivity to IPv4 networks. Teredo is documented in RFC 4380 published by the Internet Engineering Task Force (IETF). Windows XP SP2 and later provide support for a virtual Teredo adapter which can provide a public IPv6 address in the range 2001:0::/32. This IPv6 address can be used to listen for incoming connections from the Internet and can be provided to IPv6 enabled clients that wish to connect to the listening service. This frees an application from worrying about how to address a computer behind a NAT device, since the application can just connect to it using its IPv6 Teredo address. 22 settembre Do you hear what I hear? Silver bells, Silver bells...Do You Hear What I Hear? although, it's already September and the start of *BER months means it's Christmas season, It's not a Christmas song that I'm referring to
Taken from MSDN:
"The System.Net.Sockets namespace in Silverlight version 3 provides a managed implementation of the sockets networking interface for developers who need to tightly control access to the network. On Windows, the System.Net.Sockets namespace provides a managed implementation of the Windows Sockets (Winsock) interface. On Apple Mac OS X, the System.Net.Sockets namespace provides a managed implementation of the sockets interface based on Berkeley Software Distribution (BSD) UNIX."
One additional restriction on using the sockets classes is that the destination port range that a network application is allowed to connect to must be within the range of 4502-4534. These are the only destination ports allowed by a connection from a Silverlight application using sockets. If the target port is not within this port range, the attempt to connect will fail. It is possible for a target server to receive connections on a port from this restricted range and redirect it to a different port (a well-known port, for example) if this is needed to support a specific existing application protocol.
To deploy a security policy file on a server for sockets, system administrators need to configure a separate authentication service on port 943 for each IP address that is to provide the policy file definition.
This is cool since I didn't omit the TCP support in my network library, including support for asynchronous sending and receiving operations.
29 settembre What to send and how?
The sender manager members: Complete Overview
Data writers class members:
07 settembre What's inside the message?Before I'll tackle how to grant access to a connecting client or denied the request, I will fast forward a little bit and
talk about how to read messages received by the server.
Since I want Z-Communicator optimized on the receiving part behind the scene, at the socket level where the actual
receiving of packets is happening, other than that, there is no need to implement events or delegates on using
Z-Communicator, everything happening at the socket level will be reported via messaging.
Like for instance, If the server receives an incomming connection, a connected client requesting to create/join/leave
a game session or client asking for a gracefull disconnection, etzetera... etzetera... I will received an informative
message data from the server message manager "_Server.MessageMngr", and take appropriate action for that
particular message.
Z-Communicator have it's own custom data message type format, than just throwing a raw bytes coming from socket,
the received bytes format should conform with the custom format the system have, if the received bytes format does
not conform in any of the available message format it will be discarded and record it to the logger manager, telling
me that an alien bytes format is trying to get into the system
security purposes at the same time. my implementation assures the that if I got a message it's an informative one
and not a garbage data
Message manager members:
See: Complete overview
To be able to read messages from the message manager, a simple steps are need to be implemented,
just create a network message processing routine/method, which will be call from the main program
on every game update cycle, in reference from above image, this is how to implement it in code:
1. Begin reading messages.
2. Loop while there is available message to read.
3. Read the message.
5. Process message base on message type.
6. End reading messages.
/// _____________________________________________________________ {
//!* 1). Begin reading messages.
_Server.MessageMngr.BeginReadMessage();
{
ZNC.Message m_Message = _Server.MessageMngr.ReadMessage();
{
//!* SYSTEM SPECIFIC-MESSAGE DATA TYPES:
//!* GAME SPECIFIC- MESSAGE DATA TYPES:
//!* Meta data message type
case ZNE.MessageType.METADATA:
//!
this.ProcessMetaDataMessage( m_Message ); break;
//!* Text data message type
case ZNE.MessageType.TEXTDATA:
//!
this.ProcessTextDataMessage( m_Message ); break;
//!* Object data message type
case ZNE.MessageType.OBJDATA:
//!
this.ProcessObjDataMessage( m_Message ); break;
//!* Raw bytes data message type
case ZNE.MessageType.BYTESDATA:
//!
this.ProcessRawBytesDataMessage( m_Message ); break;
//!* Voice data message type: ( under development )
case ZNE.MessageType.VOICEDATA:
//! //!* FILE HANDLING SPECIFIC-MESSAGE DATA TYPES:
//!* File data transfer, message advisory.
case ZNE.MessageType.FILEDATA:
//!
this.ProcessFileDataMessage( m_Message ); break;
//!* Download file from web, message advisory.
case ZNE.MessageType.DOWNLOADDATA:
//!
this.ProcessDownloadDataMessage( m_Message ); break;
//!* Web data message advisory.
case ZNE.MessageType.WEBDATA:
//! }//!switch
}//!While
_Server.MessageMngr.EndReadMessage();
logic for some time within the while( _Server.MessageMngr.MessageIsAvailable() ), because overtime I'm
expecting data to arrive. Nah, that is not the expecting case, that's why there's a begin read message -
"_Server.MessageMngr.BeginReadMessage()" declaration before reading all available data, It will only read
data that has been qued up since the last call from BeginReadMessage and all other messages that has been
left or currrently just arriving(which is happening in the background) will be read to the next game update
cycle, hickups and procedure blocking only comes along, if you'll be receiving thousands of message per
frame or game update which is irrational and it won't happen on a normal multiplayer games
So, What's inside the message? image below shows the members of message class where I can cast the
package DATA base on message type.
// E.g. The simplest message type is TEXTDATA, the DATA object is actually just a string type, as shown below:
/// _____________________________________________________________ public void ProcessTextDataMessage( ZNC.Message message )
{
//!* It's safe from here to cast the message DATA as string, since the message data type is already been knowned as TEXTDATA.
//!
string m_TextMessage = ( string )message.DATA;
if( message.Command == 10 ) // Say, 10 is my user-defined game command for my chat box message board.
{
_ChatMessageBoard.InsertMessage( message.SenderName, m_TextMessage );
}
else if( message.Command == 11 ) // Say, 11 is my user-defined game command as a private message sent to me.
{
---------------------------------------------------------------------------------------------------------------------------------------------|
Well, I guess my next post should be the following
* Dealing with network system MessageType.SYSDATA, how to read ZNC.SystemData from message and what action should be taken.
* What is meta data MessageType.METADATA, sending meta data using ZNC.MetaDataWriiter and readng ZNC.MetaData from received mesage.
* What is text data MessageType.TEXTDATA, sending text data using ZNC.TextDataWriter and reading Text data from received message.
* What is raw bytes MessageType.BYTESDATA, sending raw bytes using ZNC.BytesDataWriter and reading Raw bytes data from received message.
* What is object data MessageType.OBJDATA, sending object data using ZNC.ObjDataWriter and reading Object data from received message.
* What is file data MessageType.FILEDATA, sending file data using ZNC.FileDataWriter and reading ZNC.FileData from received message.
* How to download file fom web and reading ZNC.DownloadData advisory from received message. * How to send web request and reading ZNC.WebData advisory from received message. 02 settembre Auto discoveryMy last post disscuss how Z-Communicator can start listening to clients, connecting to server, but how can a client knows,
that a particular machine created a game session or started a server for other machine station to join in, ok, this topic covers
multiplayer games on LAN or local subnet only.
Whether using UDP or TCP protocol type, my implemenation are capable of announcing a game session or server accross
the local subnet, the caster manager will take care on how the game session can be announce accross the local subnet.
The caster type below is using ZNE.CasterType.Multicast broadcasting mechanism than pure ZNE.CasterType.Broadcast
mechanism, Broadcast type is I believed already been deprecated and not supported in IPv6, ZNE.CasterType.Multicast on
the other hand works fine on both IPv4 and IPv6 protocol version implementation.
// Using ZNC = ZGDK.Net.Core;
// Using ZNE = ZGDK.Net.Enum; // Using ZNH = ZGDK.Net.Helper; //!>> 1). Creating lobby server new instance. // ZNC.LobbyServer _Server = new ZNC.LobbyServer(); //!>> 2). Preparing server network configuration
// ZNC.ServerConfig m_ServerConfig = new ZNC.ServerConfig(); m_ServerConfig.SetDefault();
// m_ServerConfig.Connection = ZNE.ConnectionType.LAN; m_ServerConfig.IPVersion = ZNE.IPVersion.IPv4; m_ServerConfig.Protocol = ZNE.Protocol.TCP; m_ServerConfig.SocketType = ZNE.SocketType.Berkely; m_ServerConfig.IPAddress = ZNH.GetMachineLocalIP(); 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.Thread; m_ServerConfig.ReceiverMode = ZNE.SReceiverMode.TcpThreadPoll; m_ServerConfig.SenderMode = ZNE.SenderMode.Asynchronous; // m_ServerConfig.ApplicationName = "Mech Rider-Z Alpha Rel. 0.002"; m_ServerConfig.LobbyName = "Dexter Channel"; //!>> 3). Start lobby server service with custom network configuration. // _Server.StartLobbyService( m_ServerConfig ); //!>> 4). Start accepting client connection.
//
_Server.AcceptorMngr.StartAccepting(); //!>> 5). Start caster manager service and start announcing the game every 300Ms.
//
_Server.CasterMngr.StartCasterService(); //
_Server.CasterMngr.StartAnnouncingGame( 300 );
Lobby server caster manager:
See : Complete overview
Well, that's it, the server caster manager already been started and the game announce the server availability accross
the local subnet for clients to join in or connect and login to server, the following code shows how the client can
automatically discover the announcing server/s.
//!>>> Client end, searching for local game/s E.g. "Mech Rider-Z Alpha Rel. 0.002" for 1Sec or 1000ms.
//
ZNC.LocalGames[] m_LocalGames = ZNH.SearchLocalGames( "Mech Rider-Z Alpha Rel. 0.002", 1000 ); Local games members:
Once a client find local game/s, yes game/s, it can search all available same game tittle creating game
session or running as a server within the local area network, it can retrieve every game server information
such as computer name, server port, lobby description and it's local IP address to connect to.
NOTE: Blog contents may be slightly modified from time to time to comply with library's latest revision for future referencing. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|