the server can't receive all of my request

[jianchic]

Hello
i send my request like this

Code: Select all

      for (int i = 0 ; i < 100 ; i++) {
           SFSObject *object = [SFSObject newInstance];
           [object putInt:@"test" value:i];
           ExtensionRequest *request = [[ExtensionRequest alloc] initWithExtCmd:@"sms_sys_initialization" params:object room:self.sfs.lastJoinedRoom isUDP:NO];
           [sfs send:request];
           [request release];
      }
     

i don't know why, the server can only receive ten requests, but the java client api don't have this problem!

[Lapo]

What is the point of sending 100 requests if a for loop?
If you are testing something this is not the proper way to do it. Never ever send messages in a for loop, it will just result in bad performance from the client side.
Each small message will incur in the network lag between you and the server, and considering that you are on a mobile device the lag will not be so small.

When you send an object put all of your data in one SFSObject and send that one. Typically on a mobile device you are lucky if you can send 10 messages/second.

[brunoma]

Hi Lapo,
I saw your reply to this and got a bit worried.
Are you saying that some extension requests may be lost or dropped if they are sent at too high of a frequency?

[A51Integrated]

Mobile devices are saddled with wireless connections, which are obviously far slower than wired ones. TCP messages are also verified transmissions - so if something happens to the packet (dropped) the system will re-attempt transmission until all packets are received on the other end and verified. Because of this, TCP is much slower than UDP - UDP doesn't verify successful transmission. So if you want to send a large number of messages to the server in a very short period of time, you're better off using UDP as apposed to TCP.

However, there is still client processing time and lag time that needs to be taken into account to process the response from each request. 100 messages in under a second is substantial - even for position updates in a race or first person shooter game. In this case, I would look at your messaging architecture to either compile more data into each message and/or reduce the number of messages to a number that is truly required by the application (I realize your code is for testing purposes, but real life scenarios rarely if ever have this type of message frequency).