On Jan 2, 2006, at 7:19 PM, zmorris@mac.... wrote:

> On Jan 2, 2006, at 10:20 AM, Randy Thompson wrote:
>
>> Zack-
>>
>> Is this just a testing issue, or does the ConOps of your network game  
>> strategy really include launching a joiner on the same machine as the  
>> host at almost the same moment?

> Hey thanx for the replies.  This is all for our game Khufu, which is  
> almost peer to peer because the host is playing too, and not just a  
> server somewhere.  I have been experimenting for 10 years with various  
> networking methods, and am using NetSprocket so I can make sure the  
> game logic really works, without having to worry about the lowest  
> level stuff.  I don't think the problem is with my logic, because when  
> I call NSpGame_Host() then immediately NSpPlayer_GetMyID() on the  
> host, I am getting ids like 2.

I would have to disagree, based on what you say below the problem is  
your logic:

> In my netsprocket wrapper, I have a command to keep the client  
> retrying to join about 60 times a second (this will be slowed to once  
> a second eventually).  That way I can try to join a game that may not  
> be hosting yet, but the join happens in the background without me  
> having to babysit it.

This means that there is a request in transit (in the outgoing packet  
buffers, on the wire, or in the incoming packet buffer) to the host  
even though the host doesn't exist yet. This causes the join request  
sent by the client to be received before the host itself can join. 60  
times a second is a very high rate for network traffic, and pretty much  
guaranteed not to work in real world (internet) conditions -- by that I  
mean that the connection attempts will get bunched up and possibly even  
reordered en-route (TCP guarantees in-order delivery, but you are  
trying to establish a TCP connection, not send data over TCP) so rather  
than 60 distinct query replies you will get batches of connection  
attempts that are handled in random order.

Go ahead and slow the retry attempts to once a second now, and you  
should see a significant drop-off in the frequency of the host getting  
id 2.

> I will probably fix this by hosting the game before telling the  
> tracker that I am hosting.

Yes, this will guarantee that the host will always get id 1, and it's  
the way Net Sprocket expects to work.

> But I am concerned that hackers could just be port scanning and hack a  
> game by being the first one in.  I guess this wouldn't matter if a  
> game was properly written to not rely on the host being id 1.  I do  
> wonder what would happen if all of the clients joined and the host  
> couldn't get in on a free slot?

Even if they were port scanning, they would have to identify that the  
port they saw was a NetSprocket game port, and then run through enough  
of the NetSprocket protocol to actually join the game. This is pretty  
unlikely unless your game is very popular (ie: sells millions of  
copies) or you are giving away valuable prizes for tournaments or  
something.

Nevertheless there are ways to prevent that completely or make it  
harder:

1. Have the game shut itself down with a notice to all players that the  
game is being hacked and the IP address of the hacker if the host gets  
an Id other than 2 (it would report the remote IP address of the player  
on id 1).

2. Have the tracker coordinate the join and once all players have been  
approved to join a game by the tracker, the tracker passes their IP  
addresses back to the host so that the host knows who will be joining.  
Anyone connecting from another address will be immediately disconnected  
and not be assigned a player ID. Note that this would cause a small  
percentage of legitimate players to be dropped, because some ISPs  
(notably AOL) don't always give you the same externally visible IP  
between TCP connections, even in the same session.

3. Randomize the port you are hosting on, so only the host and the  
tracker knows what port you are on, and once the tracker knows it's  
already safe to connect because the host has connected. Note that this  
will cause massive headaches to anyone trying to configure a firewall  
or NAT to allow the incoming traffic, and you'll have to be careful to  
avoid conflicts with well known services. I don't believe this one is  
worth the hassle.

Hope this helps,
Ed

>
>> P.S.  I think I recall meeting you a about 5-6 years ago at the  
>> "NetSprocket/OpenPlay Birds of a Feather" workshop at the Apple  
>> WWDC... was that you?
>
> I think you have me confused with another Zack Morris :-P  I am just  
> yer average garage programmer out here in lil ol' Idaho and rarely  
> venture outside the state anymore.  I would love to though, next year  
> when I'm a millionaire :-P  Oh but come to think of it, I was on the  
> Uber list for a while back in college, say 1998-1999.
>
> Thanx,
>
> -----------------------------------------------------------------------
> -
> Zack Morris              Z Sculpt Entertainment               This  
> Space
> zmorris@zscu...      http://www.zsculpt.com                 For  
> Rent
> -----------------------------------------------------------------------
> -
> If the doors of perception were cleansed, everything would appear to  
> man
>   as it is, infinite. -William Blake, The Marriage of Heaven and Hell
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Openplay-dev mailing list      (Openplay-dev@list...)
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/openplay-dev/ezavada%40io.com
>
> This email sent to ezavada@io.c...
>
>
Ed Zavada
Pixel Dust Games
ed@pixe...
http://www.pixeldustgames.com/

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Openplay-dev mailing list      (Openplay-dev@list...)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/openplay-dev/subscriber%40opensubscriber.com

This email sent to subscriber@open...