Elysian Shadows

how does the server and the client work? what are sockets? UDP or TCP?

It really depends.

Good resource: http://developer.valvesoftware.com/wiki ... Networking

acerookie1 wrote:UPC or TCP?

I think "UDP or TCP" will yield far more results. A UPC (universal product code) is the bar code you'd find located on just about every item sold in stores today.

I'm currently writing on my multiplayer part of my engine - and as far as I can tell you - its a pain in the ass.
So UDP or TCP?
If you want to make somekind of a chat or anything else that can be slow - use TCP.
If you want to make a game - and I mean games like CSS, Wc3, ... - use UDP.

Client Server model:

On most modern games its something like this:
Server holds all the information and is more less 'god'
Clients just hold the data that they need to know to render the stuff what they see.
The client then asks the server something like "Can I go forward?" and the server tells them "yes you can/can't!" and sents them the new position.
But it would feel horrible this way, so the client runs the same logic as the server and "predicts" its own movement.
And use the link K-Bal posted - that is also my main resource.

And: I would advise you to use a crossplattform lib for the sockets, so you dont have to write your socket system for each OS.

For UDP vs. TCP I have to say:

I'm using TCP for my action-game and it feels good. I tested it with a friend (Ping: ~30ms) and it's not laggy at all and I've not even implemented lag compensation. You don't have to check user ids since you have one connection for each user, too. Furthermore, if you need messages to arrive and to arrive in order, then you will see yourself implementing what TCP already has available with no extra work.

I gave TCP a chance because I am lazy and it's turning out well so far

UDP is consider connectionless because it just sends data and does not do any error checking. TCP will establish a connection and send data with error checking. TCP is not be as fast as UDP because of the over head of creating a connection and resending any lost packets. The choice between UDP and TCP comes down to if you can afford to drop packets or not. Thats what I learned in networking anyway.

noob wrote:The choice between UDP and TCP comes down to if you can afford to drop packets or not.

QFE.

UDP is something I would implement for a streaming media or a multicasting (this can include Lan games) application, but I would think twice before using it in most games, and as far as I'm concerned, the overhead is negligible in most game development environments. If I ended up making a game which implemented the UDP protocol, then I would probably end up writing a partially reliable protocol on top of it because datagram reordering/dropping could interfere with the game's logic, so I wouldn't say that using UDP is any easier than using TCP.

As for the structure of data sent to and from the applications, most games format the data with a header. Usually the first two bytes are the length of the data, and then next two bytes are the type (which is used to distinguish the packets from each other, from which the application will know which offsets contain certain data). The data sent to the server from a client notifying it of a movement could be structured into a byte array like so:
The data is often written and read using the Little Endian byte order.
Of course, most games will implement a cipher for encrypting and decrypting data when it is sent and received.

If you are interested in speed or scalability, then let's talk about server threading models.

myeah.

there may be some games that get a way with TCP. chess, boggle, maybe SOME MMO's.

but if you look at any top notch FPS, its UDP. TCP will will kill you if you get in a situation where the server or client looses a packet and does not know how to send it again. your connection times out effectivly.

UDP does not give a shit, its just goes on. now do your self a test. write a few UDP clients that talk with a server that send numbers in sequential order, then in the end you can easily calculate the packets lost, it will be so few IF any on a small scale, that there is just no contest.

avansc wrote:TCP will will kill you if you get in a situation where the server or client looses a packet and does not know how to send it again. your connection times out effectivly.

Resends are done automatically with TCP.

Yes and? Like tcp never times out?

avansc wrote:Yes and? Like tcp never times out?

No. Are you talking about congestion? If that is the case, I don't see why UDP would be better in that case. Yes, the connection would not time out (since there is no connection) but the game will propably run like shit.

I can only see the result of this topic being a stalemate. Both protocols have their own practical uses and TCP shouldn't always be ruled out because there are plenty of popular MMO's that show good examples of TCP's capabilities. However, when it comes to 3D action games like first person shooters, then smooth gameplay and speed is likely to be more important than correctness, but developers will sometimes find themselves writing or using wrappers that offer TCP-like correctness over a UDP protocol. Either way, an effective socket system could rule out issues like TCP timeouts or dropped and rearranged datagrams.

Like K-Bal mentioned, it depends on what your project is. A lot of games don't necessarily need to use UDP, but you could always make provisions for it to be implemented later on in your game's development. For the more "top-notch" action games that rely on sending data quickly (spamming a bunch of movement/view packets), and not always correctly, you might want to use UDP. If you're not aiming to create games like CSS or Wc3 for a while, then you might not need to worry about UDP right now, but know that it's an option. The page behind this magical text may help get you started.

In the end, you'd (hopefullly) write a wrapper class around whatever you are using. So a network class, with send/recieve functions and whatever else. That way, its not too much work to add udp/tcp later on. All you'd have to do is change the class, the connection details, and maybe a little bit in some other areas.

Live-Dimension wrote:In the end, you'd (hopefullly) write a wrapper class around whatever you are using. So a network class, with send/recieve functions and whatever else. That way, its not too much work to add udp/tcp later on. All you'd have to do is change the class, the connection details, and maybe a little bit in some other areas.

Your right about that, thats pretty much the way i developed the networked air hockey game. It wouldn't have been too much work to switch it either way.

Just a little kind of offtopic note, ive managed to use placement new on my own structs and send them over the network, i dont know if this is a new usage, but it works and is simple, idk if its fast or secure, it stores the new struct in a char array buffer and then it sends it and then it recievs and then you can get it out of the buffer again