Posted: Sep 29, 2009 @ 03:50 PM             Msg. 1 of 7

I've read the couple threads mentioning OnDisconnected and OnLoginComplete and have been testing the process to make our app as robust as possible with the current API.

Last Friday I tested by unplugging my network cable. It seemed to take about 10 minutes before the status changed from CompleteConnected to ConnectionClosed at which point it would repeatedly bounce to InAutoReconnect for a moment and back to ConnectionClosed.

I attempted to reproduce this today with little luck. Today if I unplug the network cable or drop traffic from your server to me or drop traffic in both ways the state does not change in up to 25 minutes (as long as I am willing to wait to test.) If I only block traffic from my computer to your servers the disconnected state is detected within two minutes. I have only tested "dropped" states (packet dropping and unplugging network cable from the desktop system.) I haven't tested "rejected" ones.

What is the API doing to detect a network disconnect? How soon should it be detecting this condition?

Posted: Sep 29, 2009 @ 04:22 PM             Msg. 2 of 7

Thank you for pointing us the problem.

API has different ways to track the connection state, but it still has to rely on Windows TCP/IP subsystem to detect disconnection.

We will investigate that issue and try to reproduce this scenario. Could you please tell us more about your conditions - what version of Windows do you use, what is the internet connection type (cable/dsl etc), what network equipment do you use?

Any additional information would be greatly appreciated.

Posted: Sep 29, 2009 @ 04:45 PM             Msg. 3 of 7

Also, please be sure you are using the most current version of the API.

---

Robert Vinicky

Posted: Sep 29, 2009 @ 05:57 PM             Msg. 4 of 7

Windows Vista x64
NxT1 lines from XO & Qwest (local telco.)
Netgear and other 100mb ethernet switches, office snat through a Debian box (firewall/NAT).
OECAPICOM.dll 3.4.0.0

I have tested this by physically unplugging the computer last Friday and today and more frequently today by using various firewall rules to block traffic between my desktop computer and 74.201.3.45 in various directions and ways.

I found it interesting that the "disconnect" was noticed so quickly when I could receive packets but the ones I sent were dropped before getting back to you.

I also noticed that after plugging back in or removing the firewall block of packets from OEC server to my API instance it would either require my requesting a new history set (or any request I suppose) when I would wait 25+ minutes or one time when I only waited 11 minutes the data started flowing again a minute or three after dropping the block.

After the longer blocks I wouldn't get an OnDisconnected or OnLoginComplete and I would get a back-fill of "limit-move" looking data. Sometimes if I tried unsubscribing and resubscribing after the data had back-flowed I would then get a disconnect and a complete event.
Edited by jlanawalt on Sep 29, 2009 at 17:58:17

Posted: Sep 29, 2009 @ 06:25 PM             Msg. 5 of 7

I was running this test more as a client. I have the most recent OEC API components installed into our App's directory. I didn't have the API Development stuff installed to test this as a developer.

I'll give it another round of testing both ways to see if somehow I was linked to the wrong version of the dll.

Posted: Oct 02, 2009 @ 12:09 PM             Msg. 6 of 7

On another system where we have the latest API installed (it is our release build system) we are experiencing the same thing. When we started testing disconnect/reconnect a couple of months ago the API sent the OnDisconnect shortly after either pulling the plug or disabling the network interface.

Posted: Oct 02, 2009 @ 12:13 PM             Msg. 7 of 7

We are testing the solution for this problem and will release a fix soon.