ReliableOrdered Messages not received

[GoogleCodeExporter]

When using the ReliableOrdered transfer of messages in a bad network, if the 
message is not received by the client, the server is not sending it again.

If I send another message, than that message is pushing the previous (the one 
that was not delivered), and on the client I receive the previous message, but 
not the current.
Sometimes the current message flushes together with the previous and 2 messages 
are received.

the bad network is not simulated but it is bad (bridged on 2 networks).

Any help?

Original issue reported on code.google.com by svuc...@gmail.com on 20 Mar 2015 at 12:12

[GoogleCodeExporter]

You can control flushing by turning off AutoFlushSendQueue in the peer 
configuration. Hard to tell what might be your problem with reliable messages; 
does the samples gives the same result?

Original comment by lidg...@gmail.com on 20 Mar 2015 at 12:57

[GoogleCodeExporter]

I have tried with setting up:
m_autoFlushSendQueue = false;

and then after every:
server.SendMessage(om, Connection, NetDeliveryMethod.ReliableOrdered, channel);

I fire:
server.FlushSendQueue();

this way in debug I see that not all of the chunks are received and the message 
doesn't come at all.

In the constants I am using:
internal const int ReliableOrderedWindowSize = 4;
tried also with values like 8, 64, but nothing works.

Original comment by svuc...@gmail.com on 20 Mar 2015 at 2:11

[GoogleCodeExporter]

so this happens very often, in this network. 
If I start both server and client on the same machine, then it works all the 
time.

Original comment by svuc...@gmail.com on 20 Mar 2015 at 2:13

[GoogleCodeExporter]

Have you tried the samples? You don't need to change the 
ReliableOrderedWindowSize value. How large message are you sending? What's the 
amount of packet loss on that network?

Original comment by lidg...@gmail.com on 20 Mar 2015 at 2:47

[GoogleCodeExporter]

I can't easy try the samples, cos my client is Android and the server is 
windows.
The message is around 1-2KB, my MTU is 960Bytes, so it is 2 packets.

here is some debug output:
03-21 01:07:25.197 V/        (12811): Updated average roundtrip time to 50.51 
ms, remote time to 1736.12855212908 (ie. diff 1047.34901112908)
03-21 01:07:25.604 V/        (12811): Received fragment 1 of 2 (2 chunks 
received)
03-21 01:07:25.611 V/        (12811): Fragment group #48 fully received in 2 
chunks (9800 bits)
03-21 01:07:25.611 V/        (12811): Received fragment 0 of 2 (1 chunks 
received)
03-21 01:07:25.611 V/        (12811): Received fragment 1 of 2 (2 chunks 
received)
03-21 01:07:25.611 V/        (12811): Fragment group #49 fully received in 2 
chunks (9800 bits)

So the first sendMessage I have no output in debug, and on the second I am 
getting both messages, like the last one was not flushed. I will try to see how 
you are using the framework in the samples and will come back if I find 
something.

Original comment by svuc...@gmail.com on 20 Mar 2015 at 5:15

[GoogleCodeExporter]

Okay I checked on the samples using Windows only server and client running on 
the same PC.

In settings I put 20% loss in both client and server.

Then started to send from the client: A, B, C, D, E, F, G   -----7 messages
on the server I got: A, B, C, D, E, F                       -----6 messages

then when I send: H           ---- 1 message
I got on the server: G, H     ---- 2 messages

looks like the server is giving up of sending?

Original comment by svuc...@gmail.com on 20 Mar 2015 at 5:54

[GoogleCodeExporter]

What amount of time elapse before you sent 'H'? This sounds like perfectly 
normal behaviour if the 'G' packet is lost. Sending new packets will piggyback 
acks and it will realize the lost message and resend it.

Original comment by lidg...@gmail.com on 21 Mar 2015 at 1:58

[GoogleCodeExporter]

Yes 'G' is lost, the time before sending 'H' is maybe 10-20sec.
But how to make it to send it until received? Is there some configuration for 
this?

Original comment by svuc...@gmail.com on 21 Mar 2015 at 2:30

[GoogleCodeExporter]

For making this work for me, I have put two separate threads on both client and 
server which are flushing the queue every 4 seconds.

Probably this can be inside the library so when sending Reliable you will be 
sure that the other side always receives the message.

Original comment by svuc...@gmail.com on 23 Mar 2015 at 1:26

[GoogleCodeExporter]

We've the same issue and the workaround with flushing every 4 seconds seems to 
help us to resolve this.

Original comment by vladimir...@gmail.com on 17 Jun 2015 at 6:25

[GoogleCodeExporter]

Have you synced the latest code from github? There was a bug related to 
flushing fixed some time ago (commit 9878bb3f01ba2d23793c7dd390bd1d98d7a97575)

Original comment by lidg...@gmail.com on 17 Jun 2015 at 6:49

• Changed state: Accepted