Unexpected behaviors when joining room with iPads

[touchknow]

Hello,

We have noticed unexpected behaviors with the Objective-C API iPad (IOS 3.2 and 4.2) for ES 5.1 (we have a 1,000 CCU license) when trying to join rooms.

We have created a zone and a room on the server with no special parameters. When there are not many people in the room (i.e. a dozen people) everything works perfectly for iPads (They receive the onJoinRoomEvent).

However once we reach about 13-14 people the new iPad clients which tries to join a room don't receives any event while java or flash clients works perfectly (receive the onJoinRoomEvent).
After some researches into the code of the API I assumed that the bug comes from the fact that when many people are in a room, the messages received by iPad are too big and therefore there is a reception problem. (The connected user list into the room is too long)
I have tried to set to false all the EsjoinRoomRequest parameters (receivingRoomListUpdates, receivingRoomAttributeUpdates, receivingUserListUpdates, etc.) and it works, we can join 25 iPad at least to the room (we couldn’t test with more).
I would know whether this was due to a bug or if it is a limitation of the device (so forced to delete all these events even for a relatively small number of users with the iPad)?

Sincerely,
Yannick

[tcarr]

Thanks very much for this bug report. I'll have to discuss it with the team and get back to you. For your testing, you should be able to have dozens of Java or Flash clients in the same room with the iPad clients, which will help get the numbers higher (have the Java and Flash clients join first). We will have to do that ourselves when we try to reproduce the problem, because we have fewer iPads than you do.

Is there also a problem with large PluginMessages? Does it help to turn ES5.1's ES Admin's message compression setting on? (I'm not sure if that compresses the user list on that event - it's for compressing EsObjects, so it would help with PluginMessages at any rate)

[tcarr]

Best practice if you are going to have rooms that have large numbers of users in them is to not listen for the various updates involving other users. If that info is needed, add a plugin to the room, and have the plugin broadcast the info. A user just joining the room could send a plugin request to get back a plugin message with the full user list, and the plugin could broadcast that user joining the room in the userEnter method. Similarly for the userExit method and a user leaving the room. Using queued messaging helps the Flash clients from getting too many socket messages a second, but if there is a problem with the iPads and large messages, you might want to stick to immediate sending instead of queued.

[touchknow]

Thank you for your prompt response.

We first discovered the bug with the iPads but we have done tests with many java clients to full the room and then with some iPads to try to reproduce the bug.
Nevertheless we didn't try to send large PluginMessages and/or compressed messages yet (we haven't had the time), so I can't tell you about these.

Otherwise I already knew this good practice, but I had not thought of because we have 60 simultaneously connected ipad at max. Anyway thank you very much for this technique, I'll use it by default.

[tcarr]

For Flash clients, even if there are only 20 users in the room, if people are joining and leaving the room quickly you could still see problems with the Flash clients getting too many socket messages per second. I don't know what the limit is but my own rule of thumb works well: try to keep the total number of messages at 20 per second or lower.