01-03-2007 08:12 PM
01-04-2007 09:18 AM
01-04-2007 02:11 PM - edited 01-04-2007 02:11 PM
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?
Regards.
Message Edited by tbd on 01-04-2007 02:13 PM
01-05-2007 04:39 PM
01-05-2007 08:37 PM
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!
01-05-2007 09:00 PM
01-06-2007 01:32 AM
@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! 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.))
Cheers!
05-17-2019 06:48 AM - edited 05-17-2019 06:51 AM
And finally, after 12 years, a possible answer was found!
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!
05-17-2019 10:41 AM - edited 05-17-2019 10:42 AM
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().
05-20-2019 08:34 AM
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 ) and I do not recommend its use in real applications (I didn't inculde it in my final client application).
Regards,
Daniele