The error you have reported has nothing to do with a custom Extension message sent from client to server. In fact this error states the opposite. It is complaining about a non logged in client trying to invoke Extension commands... and failing because users needs to be logged in before the can interact with custom server side code.
When you say "logged in" what do you mean? In our implementation... users connect and are moved into a matchmaking room. Then we have an interval timer that gets groups of users from the room and moves them into new rooms for games.
Is api.joinRoom() truly synchronous? Why have a server-side event then? Maybe just to keep architecture consistent? I have a strong feeling it is not. My reasoning is as follows:
This game has been played by many people for around a year. So in general... it works and we don't see an issue where users are trying to send messages to a room they dont belong to yet (we don't see the error about sending to a RoomExtension vs. ZoneExtension.) When under load... I start seeing long delays between calling joinRoom() and getting the event back on the server. After I read the forum post about not needing to wait for the server event to come back... I moved the logic out of the event handler... and directly after api.joinRoom(). Only then do I start to see the error about not being able to call a RoomExtension for a room that I dont belong to.
Here is the flow that has been going for at least a year:
1) User connects and we move them to a lobby.
2) Timer fires and starts processing users in the lobby
3) For each group of users it wants to match up... it creates a room and then calls api.joinRoom() passing each user to it.
4) In the server side USER_JOIN_ROOM event handler... we send a message down to the user which says they are ready to go.
5) The client receives this message and then starts sending messages to the extension handling gameplay for the room
With this... everything works fine unless under load. Once the USER_JOIN_ROOM event starts to get delayed... it becomes very obvious that they have been sitting in a holding pattern of sorts to get into the game. In fact... we won't let them in a game that has started too long in the past.
So... when I saw the message implying that api.joinRoom() is actually synchronous... I tried the following:
1) User connects and we move them to a lobby.
2) Timer fires and starts processing users in the lobby
3) For each group of users it wants to match up... it creates a room and then calls api.joinRoom() passing each user to it.
4) Instead of waiting for the USER_JOIN_ROOM server side event... right after api.joinRoom() i go ahead and send the user a message saying they are in the room and ready to go
5) The user receives this message and then tries to send a message back to the server... presumably trying to call the room extension
6) All of a sudden... the error I posted about a user not being able to call an extension method shows up
I infer from this that calling api.joinRoom() has not completed its work... and that the user trying to send a message before the USER_JOIN_ROOM event has been fired server side is the cause the the warning about not being able to call a room extension because he isn't in the room yet. Otherwise... why would introducing a delay by waiting for the event suddenly allow the user to send messages with no warnings? Again... the warnings only showed up when i tried to send a message to the user before the server side event was fired.
Also... realize that even a perfect api and system can be messed up by people not using it correctly. Our main question is why does the server start to have such a delay between joinRoom() and the event being fired? Are extension calls and internal server events pulled from the same queue? Something seems very off for the server to take 15 seconds to fire the event... when CPU is not pegged, the client and server are on the same machine and bandwidth in and out of server from admin screen perspective is not crazy (5-20 KBps... spikes occasionally to 200KBps but for under a second). The queue screen also doesn't show anything crazy and there are no dropped messages.
It could be that we do have some extension code that is waiting for IO or something and is blocking worker threads from moving onto SmartFox internal tasks... and that would actually be the best case... because we can tune our own code. Just not really sure how I can make it visible which items are blocking the queue (if that is the issue).
There could be different choices about using the client-side ROOM_JOIN event instead of sending our own down to say they are in the room... but somewhere along the line there will be a server-side event that needs to be processed... and right now it appears that the eventing is getting slowed down and we aren't sure what metrics might help us see where the hold up is.