Network play

Member
Posts: 164
Joined: 2002.04
Post: #1
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?
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #2
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.
Quote this message in a reply
Member
Posts: 164
Joined: 2002.04
Post: #3
I guess I'll go with openplay then Smile
Do you know of any examples/tutorials on using it?
Quote this message in a reply
Member
Posts: 446
Joined: 2002.09
Post: #4
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
Quote this message in a reply
rvangaal
Unregistered
 
Post: #5
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.
Quote this message in a reply
Member
Posts: 116
Joined: 2002.04
Post: #6
Quote: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
Quote this message in a reply
rvangaal
Unregistered
 
Post: #7
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. Smile 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.
Quote this message in a reply
Member
Posts: 204
Joined: 2002.09
Post: #8
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
Quote this message in a reply
Member
Posts: 269
Joined: 2005.04
Post: #9
Quote: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. Then of course there's GameDev.net and Gamasutra. Alas, I know of no up-to-date resource for Mac networking. Let alone game networking.
Quote this message in a reply
rvangaal
Unregistered
 
Post: #10
Quote: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.
Quote this message in a reply
Member
Posts: 116
Joined: 2002.04
Post: #11
Quote: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
Quote this message in a reply
Hog
Member
Posts: 151
Joined: 2002.09
Post: #12
Quote: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.

Quote: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.
Quote this message in a reply
Member
Posts: 370
Joined: 2002.04
Post: #13
I think that you can change the data packet size of TCP connections somehow, which would significantly increase the speed...
Steven

Did you ever wonder why we had to run for shelter when the promise of a brave new world unfurled beneath the clear blue sky?
Quote this message in a reply
DoG
Moderator
Posts: 869
Joined: 2003.01
Post: #14
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.
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #15
The problem with TCP is that it's a Transmission Control Protocol Wink

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.
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  java network api San_Andreas 1 3,223 May 1, 2008 08:05 AM
Last Post: AndyKorth
  Getting network connection for a specified PID Florian 6 5,021 Dec 23, 2006 03:46 AM
Last Post: Florian
  Ways to Network. BinarySpike 28 12,613 May 10, 2005 07:44 PM
Last Post: kodex
  Network Programming henryj 9 5,470 Jan 6, 2003 07:42 PM
Last Post: henryj