Delay of Move Event in MMO

peteo

In IOS ,I send Move Event 5 times per second.Sometimes I receive the event after one second Delay.

I test it in Local area network. So what casused the delay ?

send code like this:

-(void) SendOperation:(EOperationCode)operationCode : (NSMutableDictionary*) parameter : (bool) sendReliable : (nByte) channelId
{
[_LitePeer opCustom:operationCode :parameter :sendReliable :channelId];

// avoid operation congestion (QueueOutgoingUnreliableWarning)
_outgoingOperationCount++;
if (_outgoingOperationCount > 10)
{
[_LitePeer sendOutgoingCommands];
_outgoingOperationCount = 0;
}
}

dreamora

A high load on the device can cause that so its not able to process the stuff within reasonable time anymore.

Later on, you will also need to keep 3G networking in mind which carries latencies in the range from 100ms to 5s+ along it

Boris

move events are unreliable messages. If it arrives one second late it is likely that it has actually arrived a second ago, but that a previous reliable message on the same channel arrived late.
You can try sending unreliable messages on another channel.
On the downside you might then receive these messages before you expect them, because important messages like the enterworld response or the subscribe event arrive later. So you'd have to take this into account.

Kaiserludi

Hi peteo.

Well, I am afraid, in your case your games SendOperation() method causes this delay itself.
Your code tells me, you only send outgoing operations, when 10 of them have been accumulated. Addionally you tell us, that you send move-operations 5 times per second. I guess, the move-operation will be the one, which will by far sent most often in comparison to other operations.
5 move-operations per second means, it takes 2 seconds, until 10 operations have been accumulated. Until then, the operations will be stuck in your outgpoing queue. So, the time, for which an operation will have to wait for others will be from 0 (if it is the 10th of a group of ten) up to 2 seconds (if it is the first of a group of 10) and the average wait-time will be 1 second.
So even with perfect latency there is a 1 second delay, produced by the code-snippet above.

Furthermore your approach is not avoiding congestion of outgoing unreliable operations, but deliberately provoking it, by putting operations into the queue much more often the sending content of the queue out (although you are still sending often enough to not get the queue-size-warning, if your data isn't big).

Moreover your approach can make sense for very small amounts of data, which are far from beeing time-critical, but it is not only totally unsuitable for time-critical-stuff like move-operations, it can also produce serious traffic jams, after passing a operation with a lot of data to sendOperation(), as sendOutgoingOperations() will not send out more than 1.200 bytes per call (including overhead). I guess, you can image, that it will take some time for a movement operation to come through, if you have just passed a big operation with lets say 12kb to the outgoing queue: 10 senconds with your approach, until this operation is sent out and until then a lot of already outdated movement-operations have been accumulated, all also having to go out, until the most recent will be handeled!

There is really no problem in calling sendOutgoingCommands() much more regularly, like 10 or 20 times a second, even on low-end mobile-devices, connected via mobile networks.

peteo

Thank you!
I try sendOutgoingCommands() much more regularly, it moves better.