TCP/IP Testing API

[Jon_Kokott]

The current tcp/ip testing api is problematic for testing ethernet connections.  The behavior of the function set does not allow you to bind to an ip address unless the ethernet connection is active in windows.  This means that a unit under test must be powered before binding to the connection as a host.  Additionally, powering off the unit causes the host connection to be forced to completly cycle its startup (re-bind the listener and junk all the old connections, foricbly by polling because you cannot bind to the port when no connection is present.)  

This behavior can be achieved in C program, but cannot be called by labview in a dll because all dlls exist in the same thread.  Windows tcp function calls rely on the calling thread to determine the connection, which means if you need multiple connections it simply cannot work with dll calls.  

Suggestion:

Implement TCP/IP function calls so that a listner connection can be bound to an IP address that does require an active etherenet port and that is persistent across plugging/unplugging.

[Brian_Powell]

What API are you using in C?  From what I understand about the socket API, it doesn't handle simulated connections, nor is it tied to a single thread.  Am I wrong?

Also, in LabVIEW, you can either configure the Call Library Node to always call your DLL from one thread, or to allow LabVIEW's multithreaded execution system to call the DLL from the first available thread, so I'm not sure what you mean in your second paragraph.

[Jon_Kokott]

For the C api, WINSOCK:

http://msdn.microsoft.com/en-us/library/windows/desktop/ms741394(v=vs.85).aspx

If there is another one its news to me actually.

As far as binding to a "simulated" connection (which I assume is what you're calling a NIC with no active connection) it is somewhat problematic even in that API.  I believe you still have to get that NIC up atleast once, but the connection becomes persistent upon a successful bind.

I actually wrote some winsock wrappers before the thread thing completely derailed me.  Labview Dll calls are either any thread, or single thread (is that the user.gui one?.)  With winsock, the calling thread IS very important.  Thats how it deteremines which socket you are gonna end up using.  So if you use the Single thread option in a dll call, you end up with not being able to multithread TCP connections because the DLL call will block the other function calls.  If you you use the any thread option, you have no way of controlling which one of the sockets you will get, simmilar to trying to use a functional global with reentrant calls and shared clones.

[Darren]

Any idea that has not received any kudos within a year after posting will be automatically declined.