Data Format for Socket Server Packets

by Cameron Albert 2. March 2008 22:35

For my PBBG Engine I started off programming it all for the web and AJAX. Recently I added support for sockets by porting over my socket server code I wrote for a Flash server and incorporating the code into the PBBG Engine. In a previous post about my PBBG Engine Architecture I outlined my plans for how the socket and web pieces would work together. I spent some time today refining my command pipeline and server protocol for the socket side of the engine and will probably utilize that on the web side as well.

I decided on the following format for the data packets that will go to and from the server and client. Since it is just bytes going back and forth and I wanted to keep the data streams as small as possible I decided to abandon the string based command protocol and use this instead:

The first 2 bytes of the packet will be used to store an Int16 (short) value that indicates the command to execute. I have an event being raised from the game engine that allows the implementing libraries to set the game commands. This was a Dictionary<string, ICommand> but I am going to change it to a Dictionary<short, ICommand>. That will save me some bytes back and forth without passing the command names. I can have the clientsend the proper short value for the command typed into the console or just have the links and events in the client supply the proper short value.

The next 4 bytes will be the integer length value of the message. This will allow me to know when this message ends and the next one begins.

All the bytes following up to the length value will be the actual message sent to the client or sent to the server.

The server is already validating commands, I will just need to modify to validate these bytes and watch for buffer over runs. I still need to work out validating that a logged in user is sending the information but I will work out something, maybe have the client send the encrypted authentication key to the server after a connection is opened but before commands can be processed. 

 

Comments

3/18/2008 1:27:45 AM #

Sean

So 1980's programming! Why not a soap/ws* service with a binary channel? I'm sure you know that under the covers it's using .net remoting which is pretty compact. There's probably something I'm mossing but it's because of the green beer!

Sean United States

3/18/2008 1:57:37 AM #

calbert

LOL Laughing

I don't really think it's 1980s programming. If I am going to send lots of data packets back and forth why not make them as small and efficient as possible? Also, name a successful game company that uses web services for client/server communications?

Web services are great for one time data hits, authentication, etc. but for real time server pushes and broadcasts sockets are really the only viable option.

calbert United States

Powered by BlogEngine.NET 1.5.0.7
Modified Theme by Mads Kristensen

About the Author

CameronAlbert.com I am Senior Software Development Consultant specializing in Silverlight, WPF and the Microsoft .NET Framework. 

I have released an iPhone game called the Adventures of Puppyman that was built using ExEn and am currently working on a WP7 and iPhone version of Perenthia soon to be released.

View Cameron Albert's profile on LinkedIn
See how we're connected

Follow cameronalbert on Twitter

 

Recommended Books

Silverlight 4 Business Application Development - Beginner's Guide:

http://www.packtpub.com/microsoft-silverlight-4-business-application-development-beginners-guide/book

Microsoft Silverlight 4 Business Application Development: Beginner’s Guide