You knew this was coming... BWAAAhahahaha...
Just kidding. Really appreciate your time and expertise, Patrick. Starting to feel a bit guilty about peppering you with so many questions... (but I will anyway...
Soo... I'm seeing some evidence that suggests there may be a LinkStatus variable per-phidget, rather than one "global" LinkStatus variable that applies to the entire connection between the client and a given WS host.
The evidence is as follows:
The minimal example client has a status polling loop that looks like this (pseudocode):
Code: Select all
r1 = CPhidgetInterfaceKit_getSensorValue(ifkit1, 0, &junk);
r2 = CPhidgetInterfaceKit_getOutputState(ifkit2, 0, &junk);
Examine r1 and r2 and report status;
where ifkit1 is the PH1070 IK8/8/8, and ifkit2 is the PH1014 IK0/0/4. The value of the sensor or output state is ignored; the calls are being used only to assess the client's "persistent open" idea of whether the link is currently experiencing an outage or not, via the return values.
So, while the client-WS link is being intentionally cycled up and down, the code sits in this loop. Most of the time, r1 and r2 wind up having the same value, but somthing like perhaps 2% - 5% of the time they do not, with one indicating 0 and the other indicating NOTATTACHED.
Considering that the two calls are separated in time by probably a few microseconds, it seemed difficult to explain this under the assumption of a single global LinkStatus variable as simply timing misfortune. (By "misfortune" I mean a race condition in which the global LinkStatus was 0 when the first call was made but then became set to 1 just before the second call.) With the calls separated by microseconds, it would be very unlikely to have this type of misfortune occurring 2% of the time.
I suspected that a more likely explanation might be that there is a LinkStatus state variable per phidget (and an associated heartbeat process per-phidget) so that the transition from NOTATTACHED condition to attached is asychronously determined for each phidget. With this assumption, it would not be suprising that the link statuses are sometimes are skewed by a few seconds or so (since "a few seconds" is the granularity of the attached-or-not heartbeat determination.)
Do you have any insight on this?EDIT @ 17:30 UTC:
Here's an example. The link was brought down at 1127.56 and back up 10 seconds later.
Code: Select all
openRemoteIP(PH1070): r = 0, et = 0.0001
waitForAttachment(): r = 0, et = 0.2653
openRemoteIP(PH1014): r = 0, et = 0.0000
waitForAttachment(): r = 0, et = 0.4537
20130808.1127.51: 0 (normal)
20130808.1127.53: 0 (normal)
20130808.1127.55: 0 (normal)
20130808.1127.57: 0 (normal)
20130808.1127.59: 0 (normal)
20130808.1128.01: 5 (NOTATTACHED) <--- Indicates r1 == r2 == 5
20130808.1128.03: 5 (NOTATTACHED)
20130808.1128.05: 5 (NOTATTACHED)
20130808.1128.07: 5 (NOTATTACHED)
20130808.1128.09: 5 (NOTATTACHED)
20130808.1128.11: IK1070 = 0, IK1014 = 5 <-- Indicates r1 == 0, r2 == 5
20130808.1128.13: 0 (normal) <--- indicates r1 == r2 == 0
20130808.1128.15: 0 (normal)
20130808.1128.17: 0 (normal)
20130808.1128.19: 0 (normal)
20130808.1128.21: 0 (normal)