Network play

[David]

I have no experience with any programming that is internet-related, and was wondering if anybody knows of any resources for Mac OS 9/X networking. Does anyone have any experience writing multiplayer games?

[OneSadCookie]

Don't try & do 9 & X unless you use OpenPlay. Open Transport is quite complex and few people know anything about it. Socket programming is well-understood and well-documented, and works pretty much unchanged on Mac OS X, Linux & Windows.

[David]

I guess I'll go with openplay then :)
Do you know of any examples/tutorials on using it?

[Frank C.]

Sockets can be used on OS9 by linking to GUSI: http://sourceforge.net/projects/gusi/ A carbon port is also available here: http://www.cwi.nl/~jack/macpython.html

[rvangaal]

For a game and for portability's sake (also for finding useful stuff on the net), I'd definitely go for plain sockets (socket(), bind() etc).

And for a game, look into UDP. I don't even use TCP/IP.

Things can get non-trivial though, but for LANs, a simpler UDP setup quickly works.

[wadesworld]

And for a game, look into UDP. I don't even use TCP/IP.

Um, if you use UDP, you use IP. I think you meant just TCP.

What most games do is use TCP for state-related information such as player logins or player messaging, and UDP for dynamic, quickly changing information, such as positional updates.

Wade

[rvangaal]

Indeed, I use IP, it was just that TCP isn't mentioned too often in itself.

For player messaging, be sure to handle things in a separate thread.
Actually, I myself don't use a separate thread, and it's fine. Then again, I don't use TCP. :) I use UDP for all communications; after all, you'll need reliable messages (like spawning a car) anyhow, but preferably without the timeout troubles (let alone flexibility issues) of TCP.

Also note that I use non-blocking UDP sockets. Haven't found a reason yet to do any networking in threads, frankly.

[KittyMac]

Whether to use UDP or TCP depends entirely on the type of game and the needs of the developer. For games such as racer, Unreal, and Quake where you need to least possible overhead and fastest delivery times, then UDP is the way. The gotchas you need to handle are out of order packets and dropped packets, which can be challenging issues to resolve for a novice network programmer. For games which don't depend on constant updates from a central server (Puzzle, board, or card games), then TCP is much simpler, and not noticably slower than UDP on a LAN.

For what its worth, I first programmed The Belt to use UDP, but was unable to come up with a good method for dealing with dropped and out-of-order packers, so I switch to TCP. And since it only supported LAN play, the "slowness" of TCP didn't really matter.

Either way, if you want OS 9/X compatibility, then OpenPlay (or OpenTransport for the daring) is the way to go. Haven't used OpenPlay, but I can tell you that OpenTransport is a pain in the butt with plenty of gotchas for the unwary. Check out The Belt's source code for OS 9/X/Windows compatible networking code.

Cheers,
Rocco

[Bachus]

Actually, I myself don't use a separate thread, and it's fine. Then again, I don't use TCP. I use UDP for all communications; after all, you'll need reliable messages (like spawning a car) anyhow, but preferably without the timeout troubles (let alone flexibility issues) of TCP.

I thought UDP was the unreliable one.. TCP guarantees that a packet will reach its destination. UDP doesn't.

If you're going with sockets then the definitive guide is Beej's (http://www.ecst.csuchico.edu/~beej/guide/net/html/). Then of course there's GameDev.net (http://www.gamedev.net/reference/list.asp?categoryid=30) and Gamasutra (http://www.gamasutra.com/php-bin/article_display.php?category=7). Alas, I know of no up-to-date resource for Mac networking. Let alone game networking.

[rvangaal]

Originally posted by Bachus
I thought UDP was the unreliable one.. TCP guarantees that a packet will reach its destination. UDP doesn't.

Yes, what I meant was that if you do fast-game UDP packet sending, you'll need reliable messages anyway (like 'PlayerEnters') that you still want to transport over UDP instead of TCP (well, I do, for the network layer's sake, regarding resends, statistics, bandwidth tracing etc).

So you'll need to create a way to do reliable (& ordered) UDP sending. Once you have that, there's no need for TCP anymore.

I agree though that for a lot of slower games TCP is good enough and resolves a great deal of programming effort when it comes to ordering/sequencing/dropping.

[wadesworld]

So you'll need to create a way to do reliable (& ordered) UDP sending. Once you have that, there's no need for TCP anymore.


The problem is, once you create a protocol for reliable and ordered UDP packets, you've basically added in the overhead of TCP that you were trying to avoid, so you might as well use TCP since its reliability and ordering algorithms are going to be better than yours. (Trust me on that guys - TCP has had 30 years of development by some of the brightest minds in the networking industry)

The problem with TCP is not "slowness" of sending packets. The problem is the amount of state maintained and the degredation of speed on large data transfers due to acknowledgements.

For most games that are not massively-multiplayer, those two issues are not going to be an issue - the scale just isn't large enough.

I'm not advocating using TCP for all data. Use it for data which must arrive, or which must arrive in order. Use UDP for data that can survive if a packet or two is missed.

In short - use the protocols which are already there properly and you won't have a problem. Don't spend your time trying to create your own protocol.

(If your needs are special then you may be an exception - but for 95% of game developers, using the proper protocols correctly will work fine)

Wade

[Hog]

Originally posted by wadesworld
The problem with TCP is not "slowness" of sending packets. The problem is the amount of state maintained and the degredation of speed on large data transfers due to acknowledgements.


acknowledgements don't produce that much overhead since they are piggy-backed.
tcp headers though carry much redundant information like another copy of the corresponding IP-addresses.
tcp also has special behavior like waiting 200ms or for the next acknowledgement before sending very small packets, and then sending them all at once.

Originally posted by wadesworld
I'm not advocating using TCP for all data. Use it for data which must arrive, or which must arrive in order.


UDP packets probably also arrive in the correct order, since older datagrams get discarded if they arrive later than a newer one.

[Steven]

I think that you can change the data packet size of TCP connections somehow, which would significantly increase the speed...
Steven

[DoG]

In a game, you should be able to handle lost packets, anyhow, so UDP should be of no disadvantage, though you should provide a mechanism to recognizing when a packet was lost, even if it is not necessary to retransmit it. This should be done at least for the sake of determining connection quality.

TCP can be very slow when a packet is lost. During normal operation, it is not too slow, but since all packets are transmitted sequentially, the loss of one packet means it has to be retransmitted, and the rest of the packets have to wait in line.

A little thinking should help making some abstract send and recieve interface, so you can easily change the actual transmission protocol during development, if it becomes necessary.

[OneSadCookie]

The problem with TCP is that it's a Transmission Control Protocol ;)

It has all sorts of things like speed controls, delays, congestion back-off, &c that you don't want to deal with in a game situation.

If you've got a packet that needs to get through reliably and quickly, building your own protocol on top of UDP is usually the way to go. That way you're in control.

[rvangaal]

Indeed, flexibility is the word here. For the high-end games, there's nothing wrong with just going for UDP (IMHO).

TCP is a stream indeed, so you'll need a way to distinguish packets. Although that's a matter of a single integer (16-bit perhaps), in this world of bandwidth limitations that is a first sign to look for a better approach.

Lost reliable packets can also be piggybacked on regular, non-reliable packets through UDP, giving a chance for improved bandwidth. It all adds up in small quantities (to choose for UDP instead of a mixed UDP/TCP). If only the increased complexity of your network layer.

TCP btw has a TCP_NODELAY flag to have every write() being sent immediately.

I don't know, for a game you CAN do better than TCP, as TCP wasn't targeted at speed and bandwidth as much, but reliability. It just takes time, but then again, that's what bleeding edge programming is for.