# Networking SFML Berkley Sockets

So I'm starting work on a multi-player space shooter. And I've run into some issues. As I type this, my system is currently:

//Main While Loop
Gather Input
Update Own Sprites Based on Input
Send Position Information to Server. [Owner,Obj#,Image,X,Y,Theta] (TCP)
Receive All Position Information for All Objects From Server
Update Game Screen.


Now I won't end up using this, it's for the initial networking testing phase. I'll probably end up using dead reckoning. However I have a couple questions:

1: I am using TCP for all my networking. However it jumps and skips if you drop any packets at all, so I'd like to switch to UDP and have a numbering mechanism to make sure all packets arrive. Is there a preferred Networking Schema for game communication?

2: For critical things like object hits with bullets Should I implement a second port for these important events, or just use the same UDP proto?

3: (Side Question) How should I regulate my framerate with the networked game? I don't want to have an unnecessary Sleep in each frame...

1: I am using TCP for all my networking. However it jumps and skips if you drop any packets at all, so I'd like to switch to UDP and have a numbering mechanism to make sure all packets arrive.

Then you will just have reimplemented TCP on top of UDP, and will get exactly the same symptoms you describe.

If you really can't cope with TCP - and most games can - the solution is not to code your own method of resending packets, but to ensure that most of your data can be lost without a problem. For example, object positions are rarely important enough to require a resend unless they reflect a final destination after which no further movement will be sent. Receive All Position Information for All Objects From Server is generally not practical. Receive whatever movement information is available is what you'd typically do instead.

Is there a preferred Networking Schema for game communication?

No.

2: For critical things like object hits with bullets Should I implement a second port for these important events, or just use the same UDP proto?

Use the same port. Your messages should have a flag in them that indicates whether they are reliable or unreliable. The reliable messages (ie. the important ones) will also contain a sequence number, allowing you to spot if any are missing. If one does appear to be missing (ie. the incoming sequence number is bigger than the last sequence number plus 1) then buffer the message and wait. Allow a certain amount of time for reordering (eg. 50ms, 100ms, whatever) and then ask the other side to resend whatever is missing. It's best if you can include this information inside a message you were going to send anyway, to avoid sending extra packets (which is the last thing you want to be doing when the network connection is poor).

3: (Side Question) How should I regulate my framerate with the networked game? I don't want to have an unnecessary Sleep in each frame...

The network is just an input source like any other - it has no effect on how you handle your rendering frame rate. It's often wise to separate out the logic updates so that they happen the same number of times per second no matter how fast your rendering is going: see http://gafferongames.com/game-physics/fix-your-timestep/ for more details.

• Then you will just have reimplemented TCP on top of UDP, and will get exactly the same symptoms you describe. Well Actually I was thinking of not requesting them again, and having the second tcp port take care of the vital info.. However I like your vital over the same port sequence number idea! Oh and thanks for the links! – ultifinitus May 30 '11 at 5:43
• Sequence numbers alone can't 'make sure all packets arrive' as you said - to do that, you would need to re-request the missing packets, because the only way you can be sure everything arrives is for it to keep being sent until the other side has received it. The numbers just let you know which ones you need! :) – Kylotan May 30 '11 at 11:48
• Hahahah I know! I was thinking about the unimportant packets, the important ones will most certainly have to be re-requested! =] – ultifinitus May 30 '11 at 14:29