Network Stream Timeouts

[cbutcher]

This knowledge base article, Troubleshooting Network Stream Timeouts, gives the reasons for Read and Write timeouts as follows:

Read Endpoint:

• No data available
• Connection lost on Reader side

Writer Endpoint:

• Connection lost
• "There is not yet data to be written to the writer function. Use probes or Execution Highlighting to see if data is available to be written to the Network Stream."
• Timeout too low (give more time to write the value)

What does the second point of the writer list mean? How can the node be called when data isn't available, considering the dataflow dependency on the data input?

Further, is the error when the stream is full also a timeout (for the writer, assuming that the reader didn't read enough to clear space for the writer, before the writer timed out)?

[GuilhermeCorrea]

Hello,

Have you read this white-paper?

http://www.ni.com/white-paper/12267/en/

I would strongly suggest to read it before start any usage of this API.

Good luck.

[cbutcher]

Yes - thank you for adding the link, but I have indeed read it (a couple of times, most recently just before I posted this question).

Did I miss something in there that would answer my questions?

Currently I'm writing what are effectively wrappers around the Network Stream library to provide a reconnectable stream, in the style of the Nested Endpoint Actors (or perhaps Nested Actor Endpoints?) written by Allen Smith. That library is used to provide bidirectional message passing, but I'm instead just having single direction (although can be either direction) server/client.

[Bob_Schor]

I've used Network Streams, and my interpretation of the Timeout on the Writer's side is as follows:  You give the Writer something to write.  It tries to write, but the Reader's buffer(s) is/are full.  The Timeout (I believe, though I haven't tested this) is "How long should I, the Writer, "block" waiting for the Reader to free up enough space for me to write?".  The wording in the article that you cited is, indeed, illogical, and (I believe) wrong.  Note that having a Reader without free buffer space will block the Writer, and this does not seem to be one of the conditions cited in the article, hence my suspicion that this is simply a case of "sloppy writing".

I'm happy to be shown the error of my ways ... (it's happened a few times).

Bob Schor

[cbutcher]

Thanks - that's exactly what I expected. At least, I believe that's the behaviour of the Queue API, and I'd guess the authors of Network Streams tried to make it behave in a familiar way?

There are a long list of possible errors from the NS library, but none of the others look to me more likely to be thrown (as errors) in the condition you describe. There is 

314001

Not enough free space to write.

but the positive value makes me suspect this is a warning, not a true error.

Actually, having looked through again (and perhaps more closely) for the purpose of writing this response, I don't see any timeout error for reading/writing. Maybe it only gives warnings and the boolean value? Guess this is where I go test.

Edit: Attached is a VI (saved in 2017), which demonstrates the timeout functionality. It appears that the booleans can be made to flash happily, but that errors are not produced (I also didn't see any warnings... :/). The Wait controls are a little unnecessary, since the Read/Write calls are blocking, but they can be slightly helpful to adjust timings.