2

I'm working on a relatively small shooter game project in C# that has to send over map data in chunks of voxels, together with player movement data, combat data and probably other stuff in the future. I already decided on using protobuf-net for serialization/deserialization of data between server and client but I don't know what way I should send the packets themselves. The example given by protobuf-net uses TcpListener.BeginAcceptTcpClient but warns that the example is in no way best practices. I'm aiming for supporting at least 30 users on a single server but of course I would prefer going up to 64 without it becoming too slow for the shooting gameplay to be even remotely practical. What way should I set up the TCP connection and handle packets?

Kelvin Bongers
  • 187
  • 2
  • 12
  • @Kelvin... I voted to close this question because there is no "correct" answer. I think the best best for someone at your level is to use TcpListener's async methods (e.g. async/await) to set up a listening socket. This seems like a good starting place: http://bsmadhu.wordpress.com/2012/09/29/simplify-asynchronous-programming-with-c-5-asyncawait/ – spender May 28 '13 at 20:52

1 Answers1

3

It seems kind of strange to use TCP for real-time high performance data exchange (although in some situations and depending on your network skills, you can make a case for it). Since reliability is not a core requirement but rather getting real-time world data, it makes much more sense to use a UDP connection (e.g. using Lidgren), specially when you're in a LAN setup.

Finally, here is an interesting article on the difference between TCP and UDP from a Game point of view.

dsfgsho
  • 2,731
  • 2
  • 22
  • 39
  • I was planning on moving the movement and combat data to UDP, however, voxel data has to end up EXACTLY right on the client side. It makes the difference between cover or no cover. Additionally messages like ingame button presses would also require this reliability. I'll look at Lidgreen for sending movement data but other then that I still need a TCP connection for the voxels and other stuff that has to end up EXACTLY right. – Kelvin Bongers May 28 '13 at 21:16
  • But with UDP the message can arrive EXACTLY right; you just have to check the messages manually (e.g. using headers to describe package length). And Lidgren supports this manual process very wel by providing ordered, reliable messaging over UDP. The main problem is that TCP has all sorts of buffering and other mechanisms to provide general reliability, which can make life very difficult if you have real-time requirements. I strongly recommend reading [this article](http://gafferongames.com/networking-for-game-programmers/udp-vs-tcp/) which explains the difference very well! – dsfgsho May 28 '13 at 21:47
  • Hm, fair enough, skimming over the lidgren-network basic tutorial, am I right in seeing that NetIncomingMessage and NetOutgoingMessage appear to be streams? It would be useful if I can still use protobuf-net for serializing data so I can send it easily. – Kelvin Bongers May 28 '13 at 22:01
  • 1
    Well, one of the fundamental differences between UDP and TCP is that UDP is packet-based while TCP is a stream, so you will have to figure out how to cut up your data in packets. The two class you mentioned are nothing more then wrappers around a byte array, and the samples I believe simply write from a stream to a byte array (which is pretty simple and straight forward to do if you know what your message is). – dsfgsho May 28 '13 at 22:11