gamedevlists-windows

[GD-Windows] Network code

[Carl B. <car...@ya...>]

Hello all.  This post was inspired by a recent thread on the DirectXDev mailing list, where I learned that Microsoft appears to be planning to stop developing DirectPlay by the end of the year.

I'm wondering what people here use for their network code these days.  Does everyone roll their own API based on something low-level (like UDP), or are there commercially available APIs (or open source APIs) that people have had good experiences with?.

It's been a while since I've worked on a multiplayer game, and everyone here at the office assumed we'd be using DirectPlay.  I guess we're all out of the loop.   :-)

We'd appreciate any pointers on subjects or APIs to research.  The game we are working on won't require huge amounts of bandwidth or great network performance (it's not a twitch game), but we would like to learn some up-to-date technology moving forward.

Thanks!

Carl

Re: [GD-Windows] Network code

[Brian H. <ho...@bo...>]

> Hello all.  This post was inspired by a recent thread on the
> DirectXDev mailing list, where I learned that Microsoft appears to
> be planning to stop developing DirectPlay by the end of the year.

WHAT?!  That's unpossible, DirectPlay was SO MUCH BETTER THAN ANYTHING 
ANY DEVELOPER COULD DO BY THEMSELVES!!!!!!1111  (Sorry, inside joke 
for anyone that remembers that thread from the Tony Cox days).

> I'm wondering what people here use for their network code these
> days.  Does everyone roll their own API based on something low-
> level (like UDP), or are there commercially available APIs (or open
> source APIs) that people have had good experiences with?.

http://enet.cubik.org, all your UDP goodness you'll need or want.  
It's low level and implements reliable-on-UDP, but high level stuff 
such as managing object state is still up to you.

Brian

Re: [GD-Windows] Network code

[Mike <mi...@ge...>]

we use HawkNL with pretty good results, it is a layer above sockets, 
provides a number of message types and is cross-platform.

www.rakkarsoft.com also provide their own network API that is freely 
licensable if you email them nice ;}

i'm considering using rakkar's system for our v2 engine.

mike w
www.gekidodesigns.com

Brian Hook wrote:
>>Hello all.  This post was inspired by a recent thread on the
>>DirectXDev mailing list, where I learned that Microsoft appears to
>>be planning to stop developing DirectPlay by the end of the year.
> 
> 
> WHAT?!  That's unpossible, DirectPlay was SO MUCH BETTER THAN ANYTHING 
> ANY DEVELOPER COULD DO BY THEMSELVES!!!!!!1111  (Sorry, inside joke 
> for anyone that remembers that thread from the Tony Cox days).
> 
> 
>>I'm wondering what people here use for their network code these
>>days.  Does everyone roll their own API based on something low-
>>level (like UDP), or are there commercially available APIs (or open
>>source APIs) that people have had good experiences with?.
> 
> 
> http://enet.cubik.org, all your UDP goodness you'll need or want.  
> It's low level and implements reliable-on-UDP, but high level stuff 
> such as managing object state is still up to you.
> 
> Brian
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by OSTG. Have you noticed the changes on
> Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
> one more big change to announce. We are now OSTG- Open Source Technology
> Group. Come see the changes on the new OSTG site. www.ostg.com
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_idU5
> 
> 

Re: [GD-Windows] Network code

[Ivan-Assen I. <iva...@gm...>]

What's your experience (Brian's with enet, and Mike's with HawkNL)
with regards to firewalls/NATs? We have a custom reliable-on-UDP
layer, and it fails miserably on most such setups - firewalls seem to
HATE UDP.

Re: [GD-Windows] Network code

[Brian H. <ho...@bo...>]

> What's your experience (Brian's with enet, and Mike's with HawkNL)
> with regards to firewalls/NATs? 

You may want to ping the enet mailing list for a better answer, but 
it's used for Cube (?), a popular FPS in Europe apparently, and I 
don't believe it runs into any significant issues with firewalls 
(well, no worse than anyone else is running into).

Brian

Re: [GD-Windows] Network code

[Ivan-Assen I. <iva...@gm...>]

> You may want to ping the enet mailing list for a better answer, but
> it's used for Cube (?), a popular FPS in Europe apparently, and I
> don't believe it runs into any significant issues with firewalls
> (well, no worse than anyone else is running into).

(Well, calling Cube popular is a bit of a overstatement - it's
reasonably complete fun and well-rounded for a open-source project,
but it's far from the popularity of the big commercial FPSes.)

But this is a side issue.

As most (all? all but the Dooms?) FPSes Cube is built on a
client/server model, which is inherently more forgiving with firewalls
- as long as the server is outside any firewalls, and with a real IP.

Our games are lockstep peer-to-peer, and fail when all peers are
behind firewalls. Our lobby code, which uses TCP, works OK, but once
the players click "Start" and the protocol switches to UDP, most
firewalls stop forwarding their packets. (We had the bad luck of
testing on our office firewall when developing it, which had the
strange habit of keeping open UDP ports briefly after the
corresponding TCP ports were used, and opened, so the games work with
it.)

E.g. Gamespy and Xbox Live offer all-peers-behind-firewalls
peer-to-peer networking, using a central server for the initial
handshake; a complete networking lib should include such functionality
IMHO (of course, leaving the very significant and non-trivial issue of
actually providing such a server to you).

RE: [GD-Windows] Network code

[Jon W. <hp...@mi...>]

We've had very good results with UDP in general. The trick is 
of course to be NAT safe and, ideally, NAT introduction aware 
(if you're peer-to-peer). We fall back to TCP if UDP can't get 
through, and the amount of people who CAN get through with TCP 
but CANNOT get through with UDP is < 1 %.

Note that there's a bunch of people who can't get through with 
either UDP or TCP, because they're behind a corporate wall 
that lets nothing through, and that proxys connections on port 
80 to make sure it's "really" HTTP. We thought about 
encapsulating our UDP packets in HTTP, but had better uses for 
our time at that point ;-)

Someone on the thread said their lobby used TCP. Try using UDP 
for the lobby (in fact, the same socket for connecting to the 
lobby and to the peers) and you'll probably get more success.
I have a summary of the technique and pointers to a bunch of 
alternate summaries (some much better :-) at
http://www.mindcontrol.org/~hplus/nat-punch.html

Cheers,

			/ h+


-----Original Message-----
From: gam...@li...
[mailto:gam...@li...]On Behalf Of
Ivan-Assen Ivanov
Sent: Saturday, July 31, 2004 11:11 AM
To: gam...@li...
Subject: Re: [GD-Windows] Network code


What's your experience (Brian's with enet, and Mike's with HawkNL)
with regards to firewalls/NATs? We have a custom reliable-on-UDP
layer, and it fails miserably on most such setups - firewalls seem to
HATE UDP.


-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
_______________________________________________
Gamedevlists-windows mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_id=555