Unable to establish network endpoint connectivity from an executable using localhost - error: -314350

[jajacek]

You've come to the point: "context" parameter is NOT optional, and that fact should be clearly stated in the Network Streams documentation.

Best regards

Jacek Jemielity

IEn O/Gdansk

[PontusMarkstrom]

Hi everyone,

Solutions to sv123's problem have been discussed in this thread, and hopefully the problem has been solved for the people involved. Hovever, I had the same problem recently, i.e. I used network streams to communicate between two executables on the same computer. I too received the error code -314350. As discussed, it was the "context" entry that was missing in my applications. The link provided by reddog (see section 2. About Streams>Endpoint URLs) essentially explains everything, but for those of you that still have trouble with the actual implementation in your VIs, this link gives an explicit example:

http://zone.ni.com/reference/en-XX/help/371361K-01/lvconcepts/endpointurls/

See the last section called "Streaming to an Application on the Local Host". Follow this example, and it will work for you too.

[jajacek]

Hello, 

A good idea is to generate a random text as a context for NS_CreateWriter.vi or NS_CreateReader.vi. A convenient example of such a randomly generated text is a GUID (Globally Unique Identifier). 

There are two benefits of such a solution:

- You do not need to invent and remember the context name.

- When one application has a poll of reader or writer endpoints several other applications can establish a connection at the same time because they all have always different contexts. In this way you can build a server that communicates with clients by a Network Stream. 

Best regards

JJ23

[Matt_Dennie]

Apparently this problem comes up every once in a while, as I was recently confronted with it.

I've read through the thread and understand the solution, but the problem in my case is not because of  non-unique stream names.  The trouble is stated reddog's post, but is easy to miss so I will highlight it here:

reddog wrote, "To facilitate this, each endpoint is registered in a named context, and only one application can create endpoints in that named context.  If a second application tries to create an endpoint in a named context already being used by another application on that machine, you'll receive error -314350."

When more than one application running on the same machine tries to create endpoints using "default" context, only the first application will be able to create endpoints even if the "names" are unique.  This is because only the first application will have rights to create endpoints in that default context.

I just wanted to add a bit more clarity in case anyone else struggles with this.

[Oligarlicky]

Why isn't the default behavior to generate a random, very likely unique context?

[StarSarina]

Hi Oligarlicky,

If you feel strongly about this (making a new default), we do have a NI Idea Exchange page (http://forums.ni.com/t5/NI-Idea-Exchange/ct-p/ideas) and you may want to add this idea to that forum. The R&D department looks at these ideas for future improvements.

Regards,

[nanocyte]

---

@Bob_Schor wrote:

 ":MyApp.exe/reader" instead of simply "/reader"

---

Just for future readers, the former isn't a valid URL right? I got error –1950678935. You'd need to type out //localhost:MyApp.exe/reader. The documentation says the localhost should be inferred

---

 If host_name is left blank, localhost is inferred.

---

but I guess that's wrong. Oddly, the context or the endpoint name are both superfluous. It doesn't have to match anything at the other end at all. It just has to not collide with anything.