Network Streams (NS) - crash scenario at passive endpoint

[Blokk]

Hello,

I am going to test this behaviour soon, but I am curious and might get answer here faster.

Imagine two PXI systems. On my "master" PXI I create a NS Writer Endpoint and specify the other PXI's URL (so this will be the active endpoint). In the "slave" PXI, I create the NS Reader Endpoint, and only specify a name for this, no URL (passive endpoint). A white paper describes what happens in case of crash of an active endpoint (passive endpoint will hang forever): http://www.ni.com/white-paper/12267/en/ (see under section: "Connection Management and Reconnections"). This scenario is not a problem for me, I consider the master PXI always running, if crashes, we have another protocol which will deal with this case.

However, I am curious what happens when the "slave" PXI crashes with the passive endpoint? I manually restart the slave PXI so the "Create NS Reader" VI executes first, then next the "Read Single Element from Stream" VI should start to operate. Will the stream recover from such crash by only restarting the slave PXI, or do I need to restart the master PXI too?

[Blokk]

After some testing using two laptops on a local network, I got some idea how to handle possible crashes. There is of course a difference between a network outage or when the application itself crashes. I tested network problems by turning temporary the network off on each of the laptops. It looks like the Network Stream handles such scenario well: either I turned off the network at the active or at the passive endpoint, it recovered after turning it back.

Of course, in my real application I will wrap up the NSs into an Action Engine, and I will use some timeouts and handle these errors. In this case, even if I need to restart either the active PXI or the passive one, the Network Streams will automatically recover (need to program some state machine which tries to reconnect the endpoints in case of timeout and other errors).

Active endpoint side:

Passive endpoint:

[Bob_Schor]

I have to admit I'm confused by the terms "Master/Slave" and "Active/Passive".  At one point, it sounded like the Master PXI was the Passive Endpoint, yet somewhere else you seemed to say that the Slave was Passive.  But never mind ...

We have a LabVIEW RT routine that uses a PXI as the Remote, and communicate using Network Streams.  We set up the Streams knowing the PXI's IP (we use four streams -- Message Stream Host->Remote, Message Stream Remote->Host, Event Data Remote->Host, Analog Data Remote->Host), specifying the PXI's IP in the setup for all the streams.

The PXI is set up to run its program when powered up, and at the end of the Experiment (or when the Host tells it to Restart), it reboots itself and starts up again.  So ordinarily, the Host finds the Remote already running and "waiting" for the Host to initiate Network Stream creation.  However, if the Host sends a Restart message to the PXI, the PXI reboots, which takes a number of seconds before it is ready to listen again.  Meanwhile, the Host closes its side of the Network Streams and goes back to its initialization code, trying to connect to the (not-yet-running) Remote.

To guard against having the Host "hang forever" if the PXI is powered off, the Host process will "give up" after a minute or so (as I recall, each Stream has a 15 second TimeOut, they are activated sequentially, and I try three times before giving up, so that makes 3 minutes ...).

Bob Schor

[Blokk]

I am designing recently how to handle crashes either when my "master" or "slave" PXI unit crashes. When it happens, the other unit's Network Stream VI will produce an error msg (Endpoint destroyed). I am thinking about that, for simplicity, I could just reboot the RT unit(s) in some cases, so I do not have to program a re-init part for the running code, after reboot the normal startup Network Stream creation at the beginning of the code will do so.

Do you use the "RT Restart Target (IP).vi" to restart your RT controller?

http://digital.ni.com/public.nsf/allkb/DFD8CB158F30788D86256E6A00755495