Network Infrastructure

Networking & Multiplayer
#21

I started with UDP and wrote my own tcp-methodes, it was quite funny because I haven´t done something like this before.
Maybe you already know it but here are some abstract tipps.

  1. Your first 2 bytes of datagrampacket should be how large your packet is.
  2. You create another byte[] out of the data copying from 3 to the length (1)
  3. You got one big, I called it SendObject, object that includes the object you wanna send, the playerinformation, is TCP, object is splited, some numbers, etc.
  4. You use some threads:
    for receiving,
    analysing,
    sending, take care, because there are some racing problems. I solved it with arrayLists.
  5. Objects bigger than 64 kb are splited, the splited byte[] is the object in the “SendObject”, I create a hashmap with the number of the splited Object (I give every SendObject a number, SendObjects including splited Objects get the same number to put it back together, what part is it and how much parts are there. That´s faster than tcp because you don´t care about the order, but you have to make sure, that lost packets are send again.
  6. Don´t care about player positions, if they are lost, they are. It could be that packet 1 arrives after packet 2 -> you ignore packet 1
  7. If you have to care about the order, (I haven´t needed it yet), you just wait with sending packets until the receiver responded.
  8. Server-conntection:
    Client klicks on “start server” -> server starts -> host connects
    It´s a matter of opinion, but I did it like that, because in order it´s easy to create a “stand alone multiplayer-server” for a root-server.
    Maybe some solutions aren´t perfect but I am just a try and error commander -> works well :wink:
#22

Please not the UDP is faster thing again. It was once upon a time around the mid 90’s. Nowdays this is just not true. More often than not TCP is faster, hell even in the 90’s TCP was often faster because modems etc could heavily compress the ip packet headers because TCP is state full.

This is still true to an extent today. Some of my test around the EU gave slightly better results for TCP than UDP. Even globally the strongest claim that could be made was TCP is no slower. Often routers etc prioritize TCP data over any UDP data, so once things get busy, UDP has more problems as well.

At best on a normal network it can’t be slower, its still the same IP packets over the same network.

Once packets are getting dropped or reordered (almost never happens without packet loss), then everything doesn’t work well. We have been fine tuning TCP for a long time.

There are 2 things most people don’t get right when they roll there own TCP. By far the biggest is flow control. If you lose a packet, then send 2 packets (one replay packet and one new data packet)… but you lost a packet because the network is already struggling, now you sending more trafic… this eventually results in congestion collapse. It even happened a few times to the whole internet while TCP was still getting fine tuned.

The next mistake is packet fragmentation. Often these issues are even bugs in various TCP stacks. There are less now, but over all the stack will fragment for you and you don’t need to chop packets up into the MTU for the link. Since you don’t even know the MTU for the link there is not much you can do about it. Of course the stack now needs to wait till it receives all pieces before you see any of the packet, And your back to streamed data anyway.

UDP makes sense in a very small subset of network games. Namely a game where the entire state can fit into a single packet. Flow control and packet loss are dealt with the same way. Just wait to the next packet, packets are sent at a fixed rate. This is sort of known as the quake 3 protocol and is now used in just about every FPS.

But once the whole state does not fit into a packet… Well most MMO games now use TCP. In fact many games a switching back to TCP.

If you don’t know what the 2 generals problem is, or what flow control is. Don’t do UDP… TCP is just a better fit for what most people need and will use.

#23

ProTip: Build a simple application that sends and receives a mockup of your network data structures, then raid you friends’ computers and test it on as many different systems as possible.

For all the frustrations network development has, nothing beats having the user needing to deal with network issues, as it can kill interest in your game very fast.

(Yes, very obvious advice, but it needs to be repeated… No, it’s not that I’m bitter after butting heads this weekend with R6V2’s LAN configuration >:( )