ReliableOrdered Messages not received about lidgren-network-gen3

[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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] on 23 Mar 2015 at 1:26