Advanced "Create Network Stream Endpoint" should be interruptible

[igagne]

I think there should be a way to have a network stream endpoint creator continuously wait for a connection. The problem with that is there's no good way to stop that "wait forever". I propose we create the network stream in two parts. The first one just creates a handle that can be closed later. The second one does the actual waiting like the normal create endpoint.

[crossrulz]

That's what the Timeout input is for.  If you don't connect, you retry or close.

[igagne]

Couldn't you miss a connection while you are between retries? or possibly drop a connection that would have taken if you had waited just a little bit longer? Doesn't that seem like unnecessary processor load?

[crossrulz]

If you missed a connection due to being between retries, you have at least one of the following issues: 1) not a long enough timeout on the module you are trying to connect to and/or 2) way to much time is passing between retries.  And the waiting does not bog down your CPU.

[AristosQueue (NI)]

crossrulz has the correct answer for this suggestion.

[Darren]

Declined for reasons listed here: http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Advanced-quot-Create-Network-Stream-Endpoint-quot-shou...

[igagne]

Obviously this wasn't a popular idea but I don't think the timeout satisfies the intent of the idea. The idea was to make the node asynchronously interruptible. The clear advantage of this is to have the listener stop immediately without waiting for the timeout.

But out of curiosity, can you point me to a reference design that accomplishes the behavior shown in the diagram in my idea? I’m guessing it’s going to have a great deal more complexity than what I proposed.

[crossrulz]

Here's the main problem with this idea: When the Open returns a reference and no error, it implies that a connection way made.  So then when the user tries to send after a failed connection (without knowing it), they go "WTF?  I why am I getting an invalid connection error?"

So what do I do for this?  The connection is a single state in my state machine.  If the timeout happens, I just make sure the "Connect" state is queued up again, allowing me to do other stuff in my state machine before trying again.  It is nothing fancy.  More complicated than your proposed solution?  Maybe slightly (as in a single step in a scale from 0 to 100).

[igagne]

Maybe I was unclear. My "open" is a new primitive. It's not an open at all, it's a "Create network stream handle". When that returns a handle and no error it just means it created a handle. Once you have that handle, you can pass it to "open" which actually does the opening. The user would still be able to wire a string into open which would behave the same way it does now.

I can see where you think other ideas are more important and should have a higher priority but I think being able to get rid of the polling architecture provides some value and the idea should not be closed.

BTW, how long of a timeout do you set? Do you also poll for the reader?

[crossrulz]

In my systems, I MUST have a connection.  So, yes, I do "poll" on both sides.  Though, technically, you are also polling in your suggestion, just in a different syntax.  If no connection exists, I cannot do anything.  Its something that OSHAA calls "safety".  So if I lose the connection, I am actually also to shut down everything and then go back to watching for a connection.  It also helps to have your network streams in separate loops than everything else.

I think my timeouts are typically in the 1 second range and if no conneciton, I am mostly just checking to see if I got a command to shut down the program.  I may also need to send a status back to some other part of my program to tell it that I do not have a connection.  After those, right back to waiting for a connection.  State machines are your friend.

So what would you do while waiting for a connection?  Try to send commands anyways and get errors?  As a user of your program, I would hate you for allowing me to attempt to send commands when there was never a connection.

[igagne]

Lets say I have one client app that connects to one or more servers. When the user clicks "connect to additional server", while the client is waiting, it's still getting data from the other servers and it's showing a message that says "Waiting for additional measurement server to respond. Stop waiting?" All the controls and indicators for that additional server are disabled and grayed. The client app should keep trying to connect to the additional sever until the user hits stop. If the user hits stop, we have to stop trying to connect immediately.