Access tp TCP socket options via .NET

[Mark Yedinak]

I need to get down and dirty with some TCP connections and need to access the low level socket options. .NET has the items I need but I'm looking for some pointers in using .NET calls on a TCP connection created using the native LabVIEW VIs. I am writing applications that are used to test the TCP functionality of another product. Therefore, I need to be able to force various TCP conditions such as generating a TCP-RST on a connection rather than the normal graceful disconnect via the TCP-FIN handshaking. The .NET libraries have a socket option that will allow me to do this but I don't want to re-write the entire TCP VIs using .NET. I would like to be able to use the .NET calls on connections I create using the LV calls.

Does anyone have any suggestions? I did find Rolf's package which provides IPv6 and SSL support. I haven't look through all of it yet to see if I could build off that. In addition, when I open the VIs they have broken arrows so I need to resolve that as well.

[Phillip Brooks]

I need to get down and dirty with some TCP connections and need to access the low level socket options. .NET has the items I need but I'm looking for some pointers in using .NET calls on a TCP connection created using the native LabVIEW VIs. I am writing applications that are used to test the TCP functionality of another product. Therefore, I need to be able to force various TCP conditions such as generating a TCP-RST on a connection rather than the normal graceful disconnect via the TCP-FIN handshaking. The .NET libraries have a socket option that will allow me to do this but I don't want to re-write the entire TCP VIs using .NET. I would like to be able to use the .NET calls on connections I create using the LV calls.

Does anyone have any suggestions? I did find Rolf's package which provides IPv6 and SSL support. I haven't look through all of it yet to see if I could build off that. In addition, when I open the VIs they have broken arrows so I need to resolve that as well.

There is a function in LabVIEW to retreive a reference to the socket. You can use this to manipulate the socket outside of LabVIEW. I used it to adjust the TCP buffer size. There is also a VI to return a UDP socket ref.

See this NI forum link...

[Mark Yedinak]

There is a function in LabVIEW to retreive a reference to the socket. You can use this to manipulate the socket outside of LabVIEW. I used it to adjust the TCP buffer size. There is also a VI to return a UDP socket ref.

See this NI forum link...

Thanks Phil,

I found the TCP_NoDelay.llb before. I have been using that to disable the Nagle algorithm. I am working with that now to configure the connection to abort rather do a graceful close. I have also tried to write a VI that would allow me to read the values back using the setsocketopt() call but so far I have been unsuccessful. The Call Library Node always returns an error. I haven't played with calling DLLs too much so I'm not sure if I'm doing something wrong in the call. Everything looks like it should work.

SOCKET_GetLingerOption.vi

[ned]

I found the TCP_NoDelay.llb before. I have been using that to disable the Nagle algorithm. I am working with that now to configure the connection to abort rather do a graceful close. I have also tried to write a VI that would allow me to read the values back using the setsocketopt() call but so far I have been unsuccessful. The Call Library Node always returns an error. I haven't played with calling DLLs too much so I'm not sure if I'm doing something wrong in the call. Everything looks like it should work.

The comments in your code, and the function prototype, are set up to call setsockopt, but the function you're calling is getsockopt. Which function do you mean to call? Also, it appears that if you're trying to set or get SO_LINGER, you need to pass a pointer to an appropriate LINGER structure (a cluster of two U16 values) as the value argument, or an equivalent array. To be safe I'd make sure that you do wire a value into any pointer input, even if it's actually an output, although LabVIEW might handle that for you.

[Mark Yedinak]

The comments in your code, and the function prototype, are set up to call setsockopt, but the function you're calling is getsockopt. Which function do you mean to call? Also, it appears that if you're trying to set or get SO_LINGER, you need to pass a pointer to an appropriate LINGER structure (a cluster of two U16 values) as the value argument, or an equivalent array. To be safe I'd make sure that you do wire a value into any pointer input, even if it's actually an output, although LabVIEW might handle that for you.

Yes, the code comments are not correct. The posted code was a quick experiment. I copied the code for the TCP_NoDelay.vi which was referenced above and I simply modified the Call Library Node configuration. I didn't take the time to update the comments. I am trying to call the getsocketopt() function. I did wire the output to a 32-bit integer. This should be enough space for the LINGER structure which is 32 bits in length. When I run this VI I always get an error returned.

I have successfully called the setsocketopt() function to set the LINGER options. However I am not sure why the call to getsocketopt() is failing every time. I have experimented with wiring something to every input parameter, not wiring anything to input parameters for arguments that are outputs, variations as to the type of data I wire, etc.

[ned]

Yes, the code comments are not correct. The posted code was a quick experiment. I copied the code for the TCP_NoDelay.vi which was referenced above and I simply modified the Call Library Node configuration. I didn't take the time to update the comments. I am trying to call the getsocketopt() function. I did wire the output to a 32-bit integer. This should be enough space for the LINGER structure which is 32 bits in length. When I run this VI I always get an error returned.

In that case, the problem is that the function prototype for setsockopt is not the same as for getsockopt. Specifically the last parameter (what you have as size, and the linked documentation gives as optlen) should be passed as a pointer. With that correct, I don't get an error.

[Mark Yedinak]

In that case, the problem is that the function prototype for setsockopt is not the same as for getsockopt. Specifically the last parameter (what you have as size, and the linked documentation gives as optlen) should be passed as a pointer. With that correct, I don't get an error.

Thanks. That fixed the problem. I figured it was something pretty basic that I was overlooking.

[Mark Smith]

I'm a little late to this thread, but I have a complete project (except the DNS lookup) around the WinSock functions so LabVIEW can support IPv6 in the code repository

http://lavag.org/fil...ls-for-labview/

This could be a useful reference if you're looking at how to get to low-level socket functions. It's VisualC++ instead of .NET.

Mark

[Mark Yedinak]

I'm a little late to this thread, but I have a complete project (except the DNS lookup) around the WinSock functions so LabVIEW can support IPv6 in the code repository

http://lavag.org/fil...ls-for-labview/

This could be a useful reference if you're looking at how to get to low-level socket functions. It's VisualC++ instead of .NET.

Mark

Thanks, I will take a look at it. I did get the functionality I needed by copying and modifying the TCP_NoDelay VI that has been referenced. Since I am writing applications to test network stacks on other devices I need to delve much deeper into TCP than what the native LabVIEW functionality provides.

On a related note, is it possible to generate packets that are not TCP or UDP based via LabVIEW? For instance, if I want to generate ICMP or ARP packets or write a RARP (yes, I know it is an arcane and antiquated protocol) server in LabVIEW.

[ShaunR]

Thanks, I will take a look at it. I did get the functionality I needed by copying and modifying the TCP_NoDelay VI that has been referenced. Since I am writing applications to test network stacks on other devices I need to delve much deeper into TCP than what the native LabVIEW functionality provides.

On a related note, is it possible to generate packets that are not TCP or UDP based via LabVIEW? For instance, if I want to generate ICMP or ARP packets or write a RARP (yes, I know it is an arcane and antiquated protocol) server in LabVIEW.

Rolf did some raw socket stuff a while ago that should be worth looking at.

[Mark Yedinak]

Rolf did some raw socket stuff a while ago that should be worth looking at.

Yes, I have a copy of that. I will have to look at it closer to see how easy it would be to generate other types of packets.