Phantom room clients

[Chris R]

I have a room variable that rests when room is empty (no clients). Recently in Union Admin I see phantom clients (clearly coming from my IP but I have exited all client instances. This is causing my variable to stay constant, which is a problem.

Should I be pinging clients and disconnecting if no response? Pointers on what to use in API?

[Toby]

Your problem description is not too clear.

What does "variable that rests" mean? (Typo for reset?)

Do your rooms stay around when empty? (They can automatically go away entirely when the last client exits.)

What do you mean by phantom client?

Union Admin not showing said client under Clients, but still a room Occupant? [that should be impossible]

Do they stay persist? Sometimes if a client disconnects, it takes a while until the server detects it fully. Usually that time interval corresponds to your timeout value, and you see log messages along the lines of "No communication from Client for xxx seconds - disconnecting." (Paraphrasing there.)

If they do appear in Union Admin, can you Kick them?

What happens if you Kick them prior to their disconnecting?

How are you detecting the empty room condition?

If you are just keeping your own count, it could get out of sync if somehow you miss a "client added" or "client left" message.

As for workarounds ... you could periodically check the room's Occupant count if you wanted,

but that could mean a delayed response (and also possibly open up a timing hole if your check

and a client coming or going happen at the wrong times).

I would try to keep any workaround as simple as possible.

[Chris R]

The room is persistent, and uses a simple Room Module (see snippet of union.xml below) to set room attribute VideoID to zero on instantiation, and to reset room attribute VideoID when client count falls to zero. Those functions are working consistently.

<room>

<id>Jumbotron</id>

<attributes>

<attribute name="VideoID">99</attribute>

</attributes>

<modules>

<module>

<source type="class">net.user1.union.roommodule.AttributeInitModule</source>

</module>   

</modules>

</room>

The room attribute VideoID reset when all clients leave the room. Observers have no effect.

In Admin clients are showing after those clients have left the room. 

I am testing this, so I am the only user, and I'm using multiple devices as clients.

The clients all show my IP (as expected). So not phantom with mystery IP, just hanging around after the client device has signed off.

I'm detecting client count in the Room Module (specific function below).

public void numClientsChanged(RoomEvent evt) {

try {

m_clients = m_ctx.getRoom().getNumClients();

s_log.info("**Number Clients Changed**");

s_log.info(m_clients);

if(m_clients == 0){

s_log.info("**Number Clients Zero**");

setVideoIDtoZero();

}

} catch(Exception e) {

e.printStackTrace();

}

}

I can kick the hangers on. They are there long after leaving.

I'm wondering if this is happening when my clients quit abruptly or because new IOS inactivity event (IOS 13+) is reportedly inconsistent. In either case maybe the server is not receiving the event because it is not firing properly from client. That's just a theory.

So my real question is how can I check each client and kick them automatically if they don't respond.

[Toby]

I'm just another Union user, trying my best to help you out here.

Exchanging messages on a forum is hardly the best way to work on a problem, but it's what we've got.

Bear with me.

You don't have to answer all these questions here - but I pose them just to make

sure you're looking those things as possible factors, and to clarify the situation.

I still am having a hard time understanding what your set up is:

Is this just a matter of clients joining and leaving the room?

Or is it one-to-one with connecting/disconnecting from the server?

You mention this:

<module>

     <source type="class">net.user1.union.roommodule.AttributeInitModule</source>

</module>  

Based on the name "net.user1.union..." that would appear to be standard Union code,

unless you have added your code to Union's code in some fashion.  That naming convention isn't needed.

For example: I have:

<modules>
     <module>                                                                            
        <id>lobby_mod2</id>
        <source type="script">lobby_mods.js</source>                                
     </module>                                                                  
</modules>

Where lobby_mods.js is a file of my own creation sitting in my union/modules/ directory.

(It would appear you are using Java vs my using JS - which shouldn't matter.)

The code you show is presumably based on  a NUM_CLIENTS_CHANGED Room event.
Are you also monitoring ADD_CLIENT and REMOVE_CLIENT events?
Do you see the messages that you log in your code in the logs?
Does everything correlate, except the number of clients is wrong?
Or are you not getting your listener called at all when you should?

You could have a listener for REMOVE_CLIENT and check for 0 clients
(or would it be 1, depending exactly when that is called?).

You say:

... just hanging around after the client device has signed off.

I'm detecting client count in the Room Module (specific function below).
public void numClientsChanged(RoomEvent evt) {

....

}

... I can kick the hangers on. They are there long after leaving.

That's confusing: what does "leaving" mean? Leaving the room? Disconnecting from the server?

[ It sometimes takes Union a while to detect a disconnection - corresponding to the communications timeout value -

but eventually it does when the client stops sending heartbeats. What value do you have for that? ]

My suggestion would be, before trying to kludge up some scheme for kicking clients,

monitor all those events carefully, check your logs, and see if you can figure out what's happening.

You also add some extra log.info calls to get more information.

Something I found useful is to have clients put things in the server logs by

sending a message of type "LOG_THIS" (my own invention) and the server action is

to take the arguments and put them in the logs.   You can make this part of a server module

or a room module.

[Chris R]

I'm going to try monitoring additional events, as you mentioned.

"That's confusing: what does "leaving" mean? Leaving the room? Disconnecting from the server?"

My client apps are on iPhones. Once the app is quit, the user leaves the room, which also means disconnecting from the server.

I appreciate you taking a lot at this. I'll post again after trying some of your suggestions.

Thanks

Chris