I’m using the 2014R2.1 WebSdk for building a custom control.
This control uses the Xojo.triggerServerEvent() to reports to the application some javascript events captured by the control itself (i.e. onmouseup, onmouseout, onclick and so on).
I have noticed that when these events are very near each other, the sequence at which the browser send these events to the application differs from the order of the events seen and processed by the application.
It is a bug?
I’m using Firefox 31 on Windows 7, WebApp running on Windows 7 x86.
Bug? No. It’s the nature of internet communications. You cannot guarantee that two messages, sent one after the other, will arrive at the destination in the same order.
[quote=125270:@Maurizio Rossi]I’m using the 2014R2.1 WebSdk for building a custom control.
This control uses the Xojo.triggerServerEvent() to reports to the application some javascript events captured by the control itself (i.e. onmouseup, onmouseout, onclick and so on).
I have noticed that when these events are very near each other, the sequence at which the browser send these events to the application differs from the order of the events seen and processed by the application.[/quote]
As Tim said, it is the nature of the Internet that messages arrive in no particular order. Internet protocol is such that when a message is sent, it goes through an undefined route to reach destination, so it can very well go around the globe if shorter routes are not available. http://en.wikipedia.org/wiki/Tcpip
If you need code to execute in a particular order, for instance onmouseup after onmousedown, use flags to prevent premature execution. For instance, you can have a flag set in onmousedown so if onmouseup fires before, it will not do anything when the flag is not set.
The very notion of “event driven programming” makes it necessary to code assuming that events occur in no particular order anyway.
The nature of the TCP protocol does guarantee the order of the data sent in a way completely independent of the route that frames takes to reach destination.
The only way to have an no particular order condition is when you have different connections and send data spread across them.
[quote=125301:@Maurizio Rossi]Hi Michel,
I don’t think you are correct.
The nature of the TCP protocol does guarantee the order of the data sent in a way completely independent of the route that frames takes to reach destination.
The only way to have an no particular order condition is when you have different connections and send data spread across them.[/quote]
The Transport Layer indeed insures the integrity of a message and makes sure all packets arrive in order for the datastream to be identical to what was sent. But it does not do the same for different messages, which are effectively different data streams over one connection.
But you do not have to take my word for this. You just bumped into it.
I have noticed that when these events are very near each other, the sequence at which the browser send these events to the application differs from the order of the events seen and processed by the application.
Whatever your personal belief in the matter, reality is here, as you report it yourself. I frankly doubt very much it could be a browser bug. But you can verify that by using different browsers.
My point was not theoretical at all. I was merely offering a possible way of dealing with the phenomenon, regardless of its possible cause.
I do not pretend to explain, or understand everything, and may very well be proven wrong. Only imbeciles can have delusions of universal knowledge. In the meantime, the important thing is to get code to work. And I may be able to share a thing or two about that. Hope this helps.
Tim was referring to different messages but it was not clear if these different messages was on different connection or on a single connection.
So to me it was not clear why you was pointing me to the the TCP protocol reference.
Just another “out of sequence” communication…
TCP protocol guarantees that the packets of a single transmission will arrive/be processed in the correct order. Each event is a separate transmission, so the packets of each event are guaranteed to be in order, but the transmissions themselves are not guaranteed to be in order.
Thank you Tim for you help.
All was clear for me from your second post.
As a note the problem shows up also when working locally on the same machine i.e. WebApp and browser are connected on the loopback network.
So the problem it is not related to the “different path” available in the Internet but it depends on the multiple connections between the client and the server.
Thank you again for you clarification.
Best regards.