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...
opensubscriber is not affiliated with the authors of this message nor responsible for its content.