search

CommandFusion / iViewer-For-Android

CommandFusion iViewer for Android
2 stars 0 forks source link

overtaking IP telegrams #97

Closed MichaelHartmann closed 11 years ago

MichaelHartmann commented 11 years ago

It sometimes overtaking IP telegrams (receive) (Android 2.3.6)

fpillet commented 11 years ago

Can you elaborate on the issue you are seeing? I'm not sure I fully understand what's going wrong for you - is it iViewer seemingly receiving UDP datagrams multiple times?

MichaelHartmann commented 11 years ago

It is sent from the transmitter 2 UDP telegrams. In Wireshak see that the telegram "1" and then telegram "2" is transmitted. In JAVA script program is but the first telegram "2", and then the message "1" is received. With the i-Pad is not the case. I know the time is not between frame 1 and 2, but I think that there are at least 100ms.

fpillet commented 11 years ago

One thing to know about UDP is that it is ABSOLUTELY LEGAL that datagrams be received out of order. This is why TCP exists: to ensure ordering and guarantee transmission of data packets.

So it is completely possible that the networking stack on your Android device delivers datagram out of order. We are checking this though, in case this is an issue we can fix in iViewer.

fpillet commented 11 years ago

Hi Michael, I ran some tests with 4 datagrams sent at 100ms intervals, and there is no overtaking for me. I suspect this is highly dependant on many factors: network load, version of the OS you are using, speed of the device, etc. Since UDP does not guarantee packet order, you may see overtaking, but there is nothing you can do. If you need guaranteed ordering in the packets you receive, you will have to use TCP.

fpillet commented 11 years ago

Just one addition to what I said above. During tests, I have even seen some UDP packet loss (i.e. sending 4 datagrams with a 100ms interval and losing the first one). Unfortunately, this is due to the nature of UDP which should be called "Unreliable Datagram Protocol". I'll see if we can improve the situation but I have little hope about this.

fpillet commented 11 years ago

Reopening this bug. With further testing, we were able to reproduce an issue where packets are received in the correct order, but adding them to list produced the wrong order (i.e. receiving packets 1,2,3,4 and adding them to list we end up with 2,1,3,4, exactly as you witnessed it).

Working on a fix, thanks for reporting.

MichaelHartmann commented 11 years ago

For me it is now no longer a problem. I have my status engine empowered to deal with the problem. Only I've been looking at the problem for a long time.

fpillet commented 11 years ago

Ok good to hear. Investigating the issue, we found an issue with JS call ordering (the datagrams are actually being received in the correct order) so that is the core issue to fix. It was not easy to get a reproducable case of out-of-order execution, so thank you for this.

fpillet commented 11 years ago

Fixed for next build.