opensubscriber
   Find in this group all groups
 
Unknown more information…

o : openplay-dev@lists.apple.com 3 January 2006 • 1:20AM -0500

Re: Host id race condition?
by Randy Thompson

REPLY TO AUTHOR
 
REPLY TO GROUP




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?

I am very familiar with the hosting/joining mechanism of NetSprocket,  
having been the person that originally ported it over to use OpenPlay  
from straight OpenTransport.  In my games (Freeverse software game  
server and clients) I do some very very strange stuff with respect to  
dynamically hosting and joining from the same machine, and I have  
never experienced the issue you are describing, but I don't doubt  
you.  I am just saying that from my experiences, this effect is  
possibly just a symptom of a different issue, somewhere above the  
NetSprocket layer.  In particular, your description of receiving join  
accepted and player joined messages out of order is (virtually)  
impossible at the NetSprocket level.  That's because the host  
generates those messages one after the other, without exception, and  
puts them on the TCP/IP stream in the correct order.  So they must  
arrive on the other side in the correct order.  Now, perhaps, there  
is an issue with the message queueing mechanism just after the  
connection is made, but I have never experienced it because I do some  
custom startup stuff (after NSpGame_Join) that I think is necessary  
to make a clean connection at your game level.  There is definitely a  
lot going on under the hood just after the NSpGame_Host() and  
NSPGame_Join() calls that you should give some time for completion.  
There is also some strangeness that was introduced when we eliminated  
some of the internal asynchronous message handling a few years back.  
(It was causing some crashes due to non-reentrant code.  If I had  
more time and money, I'd simply reinstate the asynchronous code and  
insert some mutex locks in appropriate places.)   Anyway, perhaps I  
could take a look at your code in the vicinity of NSpGame_Host() and  
NSpGame_Join() calls and I could make some suggestions?

Cheers,
Randy Thompson

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?

On Jan 2, 2006, at 6:54 AM, Ed Zavada wrote:

> I've also had problems with code that uses low level protocol calls  
> getting data from a connection before the connection has been  
> completed. I haven't had a chance to investigate to be sure they  
> were problems with OpenPlay or with my code -- the game in question  
> was required to ship with a different network layer, so it this  
> case OpenPlay was only for testing while we waited to the Publisher  
> to deliver the required network layer to us.
>
> WRT the issue with host ids, I suggest you go ahead and reject the  
> player, and have them automatically retry in 5 seconds or  
> something. Presumably that would give the host time to join. You  
> might also look into why the host is taking longer to join. Is it  
> doing some complicated game setup before joining that is making it  
> more likely to join slowly?
>
> I'm not familiar enough with the inner workings of the Net Sprocket  
> layer to comment on whether it's possible to force the host to join  
> first within the Net Sprocket code. If you find a way to do it  
> we'll be happy to consider incorporating it into the main code base.
>
> Hope this helps,
> Ed
>
>
> On Dec 31, 2005, at 3:29 PM, zmorris@mac.... wrote:
>
>> Hi, I am doing a lot of testing with launching multiple apps on  
>> my computer, and noticed that sometimes a player joins before the  
>> host.  So the player gets id 1 and the host gets id 2.  I am  
>> wondering if there is a way to make sure that the host always  
>> joins first, by basically stalling the join requests of the  
>> players.  I don't want to reject the players, just only allow them  
>> to join once the host has set up the game.
>> This really surprised me, because I designed the whole app with  
>> the idea that the host is always 1.  So I am not sure if this is a  
>> bug, but I can't really go back and reprogram everything now.  I  
>> am not programming for host changed events, and since they aren't  
>> implemented yet, I really think the host should always be 1.  Is  
>> there any chance this could be fixed, and if so, when's the next  
>> release planned?  And if that's out of the question, any  
>> suggestions on how I can go under the hood and make the changes :-P
>>
>> P.S. I have found several "bugs" related to join accepted and  
>> player joined messages.  Sometimes they don't come at all, or they  
>> come out of order, so I get one of my game messages before I get  
>> join accepted.  I have written a wrapper class around it that  
>> inserts player accepted and player joined messages so they always  
>> come, and then skips them when they come from netsprocket, which  
>> works ok for now, but I am worried about hard to find race  
>> conditions involving the player list being out of sync with the  
>> messages.
>>
>> 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/thompr%
> 40earthlink.net
>
> This email sent to thompr@eart...

_______________________________________________
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...

Bookmark with:

Delicious   Digg   reddit   Facebook   StumbleUpon

Related Messages

opensubscriber is not affiliated with the authors of this message nor responsible for its content.