LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Is it possible to extract the local port associated with a TCP connection/reference?

Greetings TCP hackers!
      LabVIEW's "TCP Open" has a local-port input which I want to leave unwired (so that the port will be assigned "randomly".)  When a connection is established this way, how might we determine local port#?  Can I use the connection-reference to determine what local-port has been allocated?  I'd rather not have to parse some DOS command-results (like NETSTAT) to get this info!
 
Cheers!
"Inside every large program is a small program struggling to get out." (attributed to Tony Hoare)
0 Kudos
Message 1 of 12
(4,009 Views)
You can use the UDP Multicast it will return all of the IP addresses and ports
Andrew Alford
Production Test Engineering Technologist
Sustainable Energy Technologies
www.sustainableenergy.com
0 Kudos
Message 2 of 12
(3,993 Views)

Hi Andrew,

      Thanks for the reply - though, I don't understand how to apply "UDP Multicast" to find the local-port associated with a valid TCP connection ID.  Would you elaborate a bit? Smiley Happy

Regards.

Message Edited by tbd on 01-04-2007 02:13 PM

"Inside every large program is a small program struggling to get out." (attributed to Tony Hoare)
0 Kudos
Message 3 of 12
(3,985 Views)
Hello tbd-

The TCP Open Connection is not going to let you leave the port input blank, it is a required input. You can generate a random number and pass it to the port input if you like, but LabVIEW will not randomly allocate a port for you. YOu will also need to know this port on the recieving side so you can properly open the connection from the client.

Xaq
0 Kudos
Message 4 of 12
(3,965 Views)

Hi Xaq,

      [In LV71] TCP Open Connection has two "port" inputs: "remote port" (can't be unwired) and "local port" (can be unwired.)

If I generate a random port#, there will be a possibility of it conflicting with a port already in use - that's why I'd like to have the lower-level routines pick-a-port which is certain to be safe.  Hmmm, following your idea, maybe I could look at TCP Open's return-error and try again if the error implies a port-conflict.

Thanks Xaq - that'll work! Smiley Happy

"Inside every large program is a small program struggling to get out." (attributed to Tony Hoare)
0 Kudos
Message 5 of 12
(3,954 Views)
The local port input is definitely optional. If you leave it unwired (or wire a zero), the OS will automatically select a free ephemeral port. If you do so, there is no reason to know what the local port is is. 😉
 
This is typical for outgoing connections. For example if you are browsing the web, many connetions are constantly established an torn down, all with random local ports. Only the server port on the other end is important. TCP is a stateful protocol and you cannot do anything else with that local port anyway, even if you knew its number. The connection is fully defined and established. Intermediary devices such as firewalls and NAT routers allow return traffic of an allowed estalished outgoing connection no matter what the local port is.
 
If the other side is a server written in LabVIEW using "TCP listen" you could of course hack something together so it sends the "remote port" (= local port for the client) information back to the client via the TCP connection. Still, seems rather useless.
 
So, the question remains: Why would you need that? 😮
 
 
0 Kudos
Message 6 of 12
(3,954 Views)


@altenbach wrote:

...If the other side is a server written in LabVIEW using "TCP listen" you could of course hack something together so it sends the "remote port" (= local port for the client) information back to the client via the TCP connection. Still, seems rather useless.
 
So, the question remains: Why would you need that? 😮

... to set-up a server that can establish an arbitrary number of connections with different clients.  A client contacts the server's known port, then a second, permanent connection is arranged (on random ports), after-which the initial connection is "torn-down" - freeing the "known" port for other clients to connect.  I can't hard-code any client local-ports, because mutiple clients may be on the same PC, so I needed a way for the permanent connection to be made on random ports of client (and server.)  At one point I thought terminating/reconnecting to the same (random) port that the client used might work, so wanted to know what it was.  And... I did implement the "hack" you described!  Smiley Very Happy  but it made me sad to look at it, so the search for an alternative!

In the words of Inigo Montoya:

"... to sum up...": I reinvented the passive-FTP connection protocol (on my own time (mostly.)) Smiley Wink

Cheers!

"Inside every large program is a small program struggling to get out." (attributed to Tony Hoare)
0 Kudos
Message 7 of 12
(3,940 Views)

And finally, after 12 years, a possible answer was found! Smiley Tongue

Attached a VI that give the local port (among other things) used by a TCP connection using the LabVIEW connection reference.

 

The VI simply use the Get raw net object and then call getsocketopt( <raw net object>, SO_BSP_STATE , ...) to obtain the info required.

 

Tested with LabVIEW 2018 under Windows 10 (with admin privilege granted, not sure if this is required).

Saved in LabVIEW 8 for maximum compatibility.

 

Cheers!

0 Kudos
Message 8 of 12
(3,023 Views)

That possibility has always existed and there have been examples floating around for over 12 years how to do it for TCP_NODELAY (disable Naggle algorithem). But there is very little reason to know the local settings for a socket.

 

TCP Open is the client side functionality and always connects to a TCP listener socket on the server initially. This listener then returns a local socket on the server side that is already connected to the local socket on the client and the listener then simply can go back to listening for new incoming requests. That is how TCP always has worked and still does. There is no need and not even a way to open a socket on the server side and connect to the already opened socket on the client side without hacking very deep into the socket interface yourself.

 

Please also note that SO_BSP_STATE is a recent option added to the socket library. It was introduced to support also IP6 network infrastructure (which is not possible to use with the LabVIEW TCP/IP functions). Before that you had to use (and still can) getsockname() and getnameinfo().

Rolf Kalbermatter
My Blog
0 Kudos
Message 9 of 12
(3,008 Views)

Hi Rolf,

just to clarify why I faced the need to know the local port associated with a TCP connection.
Last week I was debugging a multiple instance client application. On the dev machine I had two (some time more) instances of the client application, each instance was connected to a common server application. I was monitoring the network traffic using wireshark and I needed a quick way to setup a filter in order to see only the network traffic generated by a specific client instance. As far as I seen, in this situation, the only thing that differentiate the TCP packets generated from one client instance from the traffic generated by other instances is the local port (same source address, same destination address, same destination port). Thats it.


I agree that there is no real "functional" reason to dig in the socket to discover the local port associated with a TCP connection but can be usefull for debugging purposes.


I must admit that the proposed .VI code is "quick'n'dirty" (to say it in a kindly way Smiley LOL ) and I do not recommend its use in real applications (I didn't inculde it in my final client application).

 

Regards,

Daniele

 

 

 

 

 

0 Kudos
Message 10 of 12
(2,988 Views)