Page 1 of 1

Query about the SFS Pro 1.6.18 patch + one additional query

Posted: 22 Dec 2015, 07:06
by GrinReaper
Hi,

I recently found out about the 1.6.18 patch of SFS Pro and I couldn't understand what you meant by the point
Added disconnection thread pool the event in parallel without blocking the socket-reader thread.
in your release notes for the same. I hope someone could explain it to me.

Also, we've configured our Lobby Room to autoJoin. Recently, we've noticed that whenever a client joins into the Lobby, along with the joinOK response it's also receiving data about all the users connected in the Lobby at that moment (which runs into data for hundreds of users). As an example of the data:

Code: Select all

[ RECEIVED ]: <msg t='sys'><body action='joinOK' r='1'><pid id='0'/><vars /><uLs r='1'><u i='99974' m='0'><n><![CDATA[goyalanura]]></n><vars><var n='id' t='s'><![CDATA[181886]]></var><var n='userName' t='s'><![CDATA[goyalanura]]></var></vars></u><u i='101761' m='0'><n><![CDATA[hrshT]]></n><vars><var n='id' t='s'><![CDATA[159121]]></var><var n='userName' t='s'><![CDATA[hrshT]]></var></vars></u><u i='102081' m='0'><n><![CDATA[karanD3]]></n><vars><var n='id' t='s'><![CDATA[182121]]></var><var n='userName' t='s'><![CDATA[karanD3]]></var></vars></u><u i='102408' m='0'><n><![CDATA[Anit33]]></n><vars><var n='id' t='s'><![CDATA[195810]]></var><var n='userName' t='s'><![CDATA[Anit33]]></var></vars></u><u i='102410' m='0'><n><![CDATA[valentiPR]]></n><vars><var n='id' t='s'><![CDATA[158343]]></var><var n='userName' t='s'><![CDATA[valentiPR]]></var></vars></u><u i='102877' m='0'><n><![CDATA[shastri]]></n><vars><var n='id' t='s'><![CDATA[118017]]></var><var n='userName' t='s'><![CDATA[shastri]]></var></vars></u><u i='102889' m='0'><n><![CDATA[jesal007]]></n><vars><var n='id' t='s'><![CDATA[181837]]></var><var n='userName' t='s'><![CDATA[jesal007]]></var></vars></u><u i='103852' m='0'><n><![CDATA[gathani11223]]></n><vars><var n='id' t='s'><![CDATA[184473]]></var><var n='userName' t='s'><![CDATA[gathani11223]]></var></vars></u><u i='104028' m='0'><n><![CDATA[ksjak]]></n><vars><var n='id' t='s'><![CDATA[155871]]></var><var n='userName' t='s'><![CDATA[ksjak]]></var></vars></u><u i='104029' m='0'><n><![CDATA[sandy221]]></n><vars><var n='id' t='s'><![CDATA[181836]]></var><var n='userName' t='s'><![CDATA[sandy221]]></var></vars></u><u i='104234' m='0'><n><![CDATA[navinkt]]></n><vars><var n='id' t='s'><![CDATA[157485]]></var><var n='userName' t='s'><![CDATA[navinkt]]></var></vars></u><u i='104769' m='0'><n><![CDATA[deepuL]]></n><vars><var n='id' t='s'><![CDATA[155911]]></var><var n='userName' t='s'><![CDATA[deepuL]]></var></vars></u><u i='104947' m='0'><n><![CDATA[lokhj]]></n><vars><var n='id' t='s'><![CDATA[155602]]></var><var n='userName' t='s'><![CDATA[lokhj]]></var></vars></u><u i='104948' m='0'><n><![CDATA[theAC]]></n><vars><var n='id' t='s'><![CDATA[156003]]></var><var n='userName' t='s'><![CDATA[theAC]]></var></vars></u><u i='104950' m='0'><n><![CDATA[pomkho]]></n><vars><var n='id' t='s'><![CDATA[144230]]></var><var n='userName' t='s'><![CDATA[pomkho]]></var></vars></u>
We hadn't noticed this before. I would like to know why is this data being received for the clients and if there is any way to stop this data being transmitted to the clients.

Thank you :)

Re: Query about the SFS Pro 1.6.18 patch + one additional qu

Posted: 22 Dec 2015, 08:36
by Lapo
Hi,
the release notes means that patch 1.6.18 uses a thread pool for disconnecting users instead of running the disconnection process in the main socket-read loop.
This can have advantages when there are lots of connections/disconnections, especially with high traffic.
We hadn't noticed this before. I would like to know why is this data being received for the clients and if there is any way to stop this data being transmitted to the clients.
Yes this is normal.
Every time you join a Room you receive the user list, by default. If you are planning to join hundreds of users in a Room you can turn off this behavior by using what we call a "Limbo Room", that is a Room where nobody knows who's inside. So no user list is transmitted.

We discuss these aspects in the documentation here:
http://www.smartfoxserver.com/docs/1x/d ... ecture.htm

cheers

Re: Query about the SFS Pro 1.6.18 patch + one additional qu

Posted: 22 Dec 2015, 09:22
by GrinReaper
If you are planning to join hundreds of users in a Room you can turn off this behavior by using what we call a "Limbo Room", that is a Room where nobody knows who's inside. So no user list is transmitted.
We've configured the two static rooms (Lobby and TournamentLobby) as follows:

Code: Select all

<Rooms>
	<Room name="Lobby" autoJoin="true" isGame="false" isPrivate="false" isLimbo="true"
				uCountUpdate="false" maxUsers="4000">
		<Extensions>
			<extension name="RummyLobbyExt" className="com.skilrock.rummy.communication.RummyLobbyExtension" type="java" />
		</Extensions>
	</Room>
	<Room name="TournamentLobby" autoJoin="false" isGame="false" isPrivate="false" isLimbo="true"
				uCountUpdate="false" maxUsers="4000">
		<Extensions>
			<extension name="RummyTournamentLobbyExt" className="com.skilrock.rummy.communication.RummyTournamentLobbyExtension" type="java" />
		</Extensions>
		<Vars>
			<Var name="extName" type="s" private="false">RummyTournamentLobbyExt</Var>
		</Vars>
	</Room>
</Rooms>
We've setup both these rooms with the parameter isLimbo = true. I suppose I shouldn't be getting the user data in that case. Or am I missing something here?

Thank you.

Re: Query about the SFS Pro 1.6.18 patch + one additional qu

Posted: 22 Dec 2015, 09:31
by Lapo
Yes it looks correct.

Re: Query about the SFS Pro 1.6.18 patch + one additional qu

Posted: 22 Dec 2015, 12:00
by GrinReaper
Then why are we still getting the user details? :( We haven't changed the configuration since 2013!

Re: Query about the SFS Pro 1.6.18 patch + one additional qu

Posted: 22 Dec 2015, 14:17
by Lapo
I think the problem is that in your configuration you're using a property called isLimbo while in reality the property is called --> limbo
So at the moment you've defined a non recognized attribute, while the real "limbo" flag is missing, and therefore defaulted to --> false.

More here:
http://smartfoxserver.com/docs/1x/docPa ... basics.htm

cheers

Re: Query about the SFS Pro 1.6.18 patch + one additional qu

Posted: 23 Dec 2015, 05:37
by GrinReaper
Lapo wrote:I think the problem is that in your configuration you're using a property called isLimbo while in reality the property is called --> limbo
So at the moment you've defined a non recognized attribute, while the real "limbo" flag is missing, and therefore defaulted to --> false.

More here:
http://smartfoxserver.com/docs/1x/docPa ... basics.htm

cheers
Oh, yes, you're right! And we've been using isLimbo for 2 years and running now! :oops: