Hi guys,

If I wanted to write a multiplayer game to work over the internet, whats the best ways to transmit info back and forth.

The easiest in my mid would be to use winsock. Simply connect a socket to another computer and transmit info directly to it.

But are sockets up to this kind of thing or is there a faster/better method.

Thanks,
Eoin.
Posted on 2002-06-12 12:44:41 by Eóin
On Windows, sockets is actually as low-level as you can go. You have to do all the sending, connection accepting and data receiving by yourself. In fact it's much like the ReadFile (etc) API's, except with winsock you can never trust it to return any amount of data.
Posted on 2002-06-12 12:57:23 by Qweerdy
I don't know much about this, but I've thought about it before, and I would like to know if connection-less( datagram ) sockets would be the better way?

Maybe somebody else here could give you/I some better insight but my feelings are...

Playing some online games, RPG, I would think that the ideal would be a central server, such as blizzard's, and have the server/client use connection-less, my thinking for this would be so the user/client/server wouldn't have to worry about anybody else's data or the fact that they are getting it ... meaning the server shouldn't have to slow down other players while waiting for a response for somebody's slow connection, and if there happens to be some lag, I don't want to see a monster pounding on me 10-20 seconds ago, I want to see what monster is pounding on me right now.

Again, I'm not an expert on connection-less sockets or online gaming dev......someone else???

gorshing
Posted on 2002-06-12 13:00:48 by gorshing
UDP datagrams ("connectionless sockets") are certainly the way to go if your online game is to consist of any more than a handful of players at one time. There are a number of good reasons why you should consider using UDP, and a couple of things to bear in mind should you choose to do so.
Most of the internet is based on ethernet. This ancient beasty has a method of collision-avoidance which is akin to traffic on a busy road... it works like this. Imagine you have a number of machines listening to the same wire, let's imagine we are one of them and we want to use the wire. We need to wait for a break in the traffic. We hear one, and start yakking, then we realize that someone else is using it at the same time OH NO!! Collision !! We shut the hell up and wait for another break, and we have caused a retransmission error for some other poor shmoe. Now let's imagine that other shmoe is using TCP and we want to use UDP. Provided that we are on the same side of a frame relay (backbone server), and assuming that our UDP packets are small and frequent instead of topheavy, we can actually squeeze inbetween the traffic on the wire, effectively making those TCP users have to wait !!
What I'm saying is - UDP can achieve faster transmissions (with less retransmissions) then TCP under the same conditions... which is why we are seeing it being applied in File Transfers of online games (yes - that's right - UDP File Xfers).
To those steeped in TCP/IP it seems dangerous and silly to send files via this mechanism, and it is, and they don't.
They use UDP as the "underlying protocol" and they invent their own lil protocol above it, which has a mechanism for detecting out of order, missing and deformed packets. Sounds like TCP? Kinda. It has less overhead than TCP because this type of protocol does not acknowledge every single packet, and requests for retransmissions are often bundled in a single packet.
So what we have is a "virtually-connected connectionless connection".
Just how to take care of the special cases is up to you.
Posted on 2002-06-15 16:31:40 by Homer