What is the best way to handle the connected clients on the server side?
Graeme Bull - Oct 06, 2006
Wow.. this is such an open ended question I'm not quite sure where to start. Fortunately, I was able to get a bit of background information on the project and can hopefully offer a bit of direction for it here.
The question: What is the best way to handle the connected clients on the server side?
The answer:
Well, to bring this into a scope that I can handle in one post I'll quickly go over the goals of this particular developer.
First up, the application is a type of chat application and some users will be in private chats with each other along with a lobby area I think. The main goal here is to be able to tell only the users that are connected up together in one "private room" that somebody has logged off.
Now, I'm guessing that this developer has set it up so that all users are sitting in one application. In other words, all users that are connected to the application, whether they are in a private chat or not, are connected to this one application. The idea here is to make sure that we only tell the right people that we have left this private chat.
So perhaps first we'll look at how we would usually tell all users that a particular user has logged off.
On the server side we would put a function in the onDisconnect method. This will fire on the server side whenever somebody logs off. If we were in a one room chat I would probably just use the method broadcastMsg() of the application object.
Something like this on the server side:
application.onDisconnect = function(clientObj){
application.broadcastMsg("userLoggedOff", clientObj.userName);
}
Something like this on the client side:
nc.userLoggedOff = function(userName){
myText.text += userName + " logged off";
}
That's not too hard. But this particular developer only wants to tell certain people.
Now, there are tons of ways to do this. The best way is to have these private chats in their own instances of an application. That way it is foolproof that you won't be letting anybody else know. So, in this case, everybody would connect up to a common instance of the application for the lobby, and if there were private chats, then those people would disconnect from the lobby and go connect up to the private chat.
Of course, there are times when you want the user to also be able to monitor the lobby. So in this case, just don't disconnect them from the lobby and go connect them up to another netConnection to another instance.
The problem with that is that you will now use up another netConnection. Some people don't like that. The next option is to split up chats with Shared Objects.
So, each chat would be it's own Shared Object and people would just subscribe to whatever Shared Objects that pertained to whatever chats. This isn't a bad idea, but if there are enough in one application it could start to bog down a bit by taking up memory.
But in this case, how would you tell only certain users that a user has left the chat? This is where I can start to answer the part on how to manage clients on the server side.
When a client hooks up to the server the onConnect() method runs. This is where you can do your "client management" stuff. I most always create a whole new class for this and name it UserManager or something understandable like that. In here I would do the following:
1. Create a users object that lives in the server memory. This will hold the client objects (everybody who connects up) and anything else I want to remember about them.
2. Create a shared object that will hold the exact same information. This is good for debugging in the admin panel later
3. Accept the connection after doing whatever security checks you need to do
4. Most likely at this point I will set a variable to what room they are in.
By setting a variable for the client as to what room they are in, I can then control who gets what message. There are 2 ways to do this too (at least)
First up is to save the name of the shared object that pertains to the room they are in. That way, when they log out of the application, we just grab that value and make a send() call on the Shared Object. Everybody who is subscribing to that Shared Object will receive that call and nobody else. Or you could just loop through all the clients in the application and if the user has the same room name in their room variable, then make a call() call on the client object.
Keep in mind that Shared Objects run on different threads in the application than the application itself. So it is most likely more efficient to use the Shared Object approach.
I hope that gives some insight on how to mess around with client objects on the server side and what options there are to talking to them based on what is happening inside the application.