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

[sv123]

Hi,

We have two executables, one a sender and another a receiver. The receiver initiates a connection using the IP address of the sender's computer. They use the network endpoint connectivity mechanism to establish connection and transfer data. Everything (connectivity establishment, data transfer etc) works when the sender and receiver run on separate computers. If they run on the same computer the connection cannot be established and we get error message -314350 from 'Create Network Stream Reader Endpoint' VI on the receiver side. We tried using the IP address explicitly as well using localhost as the IP address. None of the options work.

Now if we run the sender and receiver VIs from within the Labview environment, on the same computer, everything works fine. Everythng works whether we explicitly use the IP address of the computer or just use localhost.

If one of the two runs as an executable and other runs in the environment, we get the same error message (-314350)

Does anybody know what seems to be the problem ?

[WillPwr]

Hello, sv123!

Check out this KnowledgeBase article - I think it may help with your issue:

http://digital.ni.com/public.nsf/allkb/E5EC6165CB0B80F78625778A0065B9DA?OpenDocument 

If you have any further questions, just let us know!

Best,

-Will

[sv123]

Hi,

We had seen this before. The error we are getting occurs when a reader is connecting to an existing writer. And none of this would explain why the problem only occurs from executables.

Thanks for your quck help.

Best.

[Ben-N]

Hi sv123!

I'm sorry to hear that you are having this issue!  It sounds to me, and I'm sure that you have gotten to this point as well, that somewhere between your program being a VI and converting this to an executable, there is some sort of mix up in the program structure.  I took the time to build a client server pair from our example files and put them in executables.  On my end, I was able to get these programs to execute as expected.  I've posted these two executables as attachments to this post.  Please try to run these and see if you are able to get this basic program up and running.

If you can, I suggest you try building this same set of programs into executables on your end.  That will help determine if the issue is with the program you are trying to convert or if it is in the Application Builder.  These programs can be found under the Example Finder and are named "Data Client.vi" and "Data Server.vi".

If you can successfully build these programs into executables, the issue is in the programs you are trying to convert.  If you cannot build these executables and execute them successfully, the issue is in the Application Builder.  If this is the case, I would suggest repairing this software by going into the Control Panels, navigating to "Add or Remove Programs" in Windows XP or "Programs and Features" in Windows 7.  Navigate to National Instruments Software.  You will need to repair both "NI LabVIEW xxxx" as well as "NI LabVIEW Run-Time Engine x.x" where the "x" will indicate a number depending on your version.

[Ben-N]

Forgot to add files, sorry.  Here they are.

[sv123]

Hi Ben-N,

The two executables work fine. Do you have the VIs that I can look at ? We are not using any specific port numbers, we are using the endpoints that are referred to by their IP addresses and names.

Thanks,

Best

[Ben-N]

Hi sv123,

The vi's I used are build in to the Example Finder in LabVIEW.  If you open LabVIEW and on the "Getting Started" screen look in the bottom right corner of the screen third from the bottom you should find a link for "Find Examples..." then choose the tab in the upper right corner to "Search" and search for "TCP" the program should find several VI's.  The examples I used to build those executables were "Data Server.vi" and "Data Client.vi".  You should try building those two into your own executables and see if you can get them to run properly.  Let us know.

[sv123]

Hi Ben-N,

These two examples are using a totally different mechanism than what we are using. That explains why there is a TCP port number variable in these two examples. The executables created on our computer from the two examples work fine. So the problem seems to be specific to the EndPoint mechanism of connectivity. Our  "Data Server" uses the Create Network Stream Writer Endpoint VI in a loop and our "Data Client" uses the Network Stream Reader Endpoint to connect to the "Data Server".

Thanks,

Best

[Bob_Schor]

I just got "bitten" by the same bug, though in a slightly different context.  It turns out that if you have more than one reader or writer on a machine, you need to explicitly add the "context" (which means the application name, e.g. ":MyApp.exe/reader" instead of simply "/reader").  In my case, everything worked in "development mode", but when I built the executable and tried to connect, it failed.  The subtlety here is the "context" when in development mode is the same, namely ":LabVIEW.exe", and since it is the same, it seems to be "optional".

Hope this helps fix your problem.

Bob Schor

[reddog]

In case anybody else runs into this problem, you might want to check out the Endpoint URLs section in the following tutorial.  To elaborate further on the issue, when creating an endpoint, you must supply a unique endpoint name that doesn't already exist in the system or an error will be generated.  This is fairly straight forward when dealing with a single application instance on a given machine.  However, if you have multiple application instances running on the same machine, things become more challenging.  If you have two applications App1 and App2 that both contain a reader endpoint named MyReader, we need to ensure the data received from the network is properly routed to each application.  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.  This is analagous to how applications on the same machine can't use the same port number when using TCP/IP to communicate.  If you don't explicitly specify a context when naming the endpoint, we'll attempt to create the endpoint in the default context (which is equivalent to the empty string).  This means things will work fine when running both VIs from the development environment since both VIs are in the same application instance.  However, if you create a built app for each VI and run both applications on the same machine, you'll receive error -314350 unless you've gone to the effort to make sure your endpoint names are unique across contexts.  The same thing would happen if you ran one VI in the 2010 dev environment and the second in the 2011 dev environment on the same machine.  I hope this helps clarify things.