Cannot reconnect on same local port using Internet Toolkit Telnet vi's

[LVite]

I CAN connect and reconnect successfully to my device during the same vi session using the LabVEIW TCP Open connection, Read/Write, and Close Connection vi's, but when I replace them with the analogous vis provided with the Internet Toolkit, reconnect attempts give the following error:

Error 60 occurred at TCP Open Connection in Telnet Open Connection.vi->LV_Telnet.vi

Possible reason(s):

LabVIEW: The specified network address is currently in use.

This is a symptom that the Close Connection vi is not working correctly. If I stop the vi I am can connect successfully the first time, but subsequent attempts fail.

Note: I've attached my code, but it requires the Internet Toolkit to view.

Thanks.

Justin
jflory@symmetricom.com

[altenbach]

I don't have currently access to the internet toolkit, but I'd think that the local port is optional (similar to TCP open).

Have you tried without wiring a local port? In this case the OS will chose a free ephemeral port and you're always good to go. Having a fixed local port for a client connection is dangerous anyway, because it might be in use by other processes (especially 1025).

[LVite]

Thanks for the QUICK reply.

By disconnecting the local port the reconnect attempt works until the system has exhausted its supply of local ports. Since my application runs continuously and logs-in and out frequently I have reached this saturation point after a few hours.

On my previous application I successfully used the standard TCP tools. However, these tools do not perform Telnet negotiations, so for my new device, which attempts to negotiate before connecting, I had to switch to the Telnet tools which has the limitation I described before.

I think this may be a flaw in the tool and therefore I plan to bring it up with NI, since I paid $500 for the toolkit, but since I'm pressed for time I though I would ping the experts first (-;

I do agree with your statement about leaving the local port unconnected to allow the system to find an available port. It is only for troubleshooting purposes that I hard code it.

Let me know if you have any other suggestions.

[rolfk]

One more thing to watch out for is that trying to open a connection to a particular destination with the the same local port in fast succession will most probably fail quite often due to the way the TCP/IP socket works.

TCP/IP does allow a virtually unlimited number of connections as long as at least one port or IP address parameter is different. You can't however open a connection twice from the same port to the same port. Now when you close a port that port is not really immediately closed as far as the socket is concerned. There is in fact a three way handshake performed where the remote side has to acknowlege the disconnect before the socket is actually really freed. Most socket implementations will return to the calling application immediately, only marking the socket for deletion but the actual disconnection may only be done after several seconds and sometimes even minutes or longer. If you in the meantime try to reopen the same port again you get an error.

So hardwiring the local port even for test purposes has a very high chance of failing on repetiteve opens.

Rolf Kalbermatter

[LVite]

That's very curious and I will keep that in mind. I wonder then why the port would be released almost immediately with the TCP Close Connection.vi and would take so much longer with the Telnet Close Connection.vi?

To me it seems like a somewhat ridiculous sacrifice to make for some added operating system efficiency. I would prefer for the vi to have a flag that would allow the user to choose to wait longer for the disconnect to really complete or simply mark the port to be disconnected, with the caution that some additional time must elapse for the local port to be reused with the same network address.

Justin

[altenbach]

Just some additional notes:

The TCP potocol has a rather complex state diagram ( for example here). Closing a connection takes time because it involves acknowledgment form both sides. When the client starts to close the connection, it goes through "FIN-WAIT 1" and "FIN WAIT 2" states and the server goes through "CLOSE WAIT" and "LAST ACK" states. If packets are lost or delayed, these states might persist for a while, but they all have associated timeouts.

Of course there are applications that break with protocol to speed things up. For example Internet explorer closes many connections one-sided with a simple RST packet to avoid the FIN exchange. (This has even confused certain firewalls in the past).

It is very difficult to imagine that you are actually running out of ephemeral ports, IIRC windows uses up to port 5000. Could it be that you use some flawed firewall software or networking device that prevents proper closing of the connection?

Maye you should hook up a packet sniffer and look at the connection closing sequence for the two scenarios (toolkit vs. plain TCP).

Also remember that the internet toolkit is probably mostly LabVIEW with unlocked diagrams. Maybe you can "tweak" it a little. 😉

Of course you could use all available ports by incremeting the local port through its full U16 range (or e.g. 10000-60000). With each new connection, increment the local port until you don't get an error (meaning the local port is not used!), then make a new connection.

Do you really need to constantly establish new connections? Couldn't you connect once and keep the connection open for the duration of the run?

[rolfk]

---

@LVite wrote:
That's very curious and I will keep that in mind. I wonder then why the port would be released almost immediately with the TCP Close Connection.vi and would take so much longer with the Telnet Close Connection.vi?

To me it seems like a somewhat ridiculous sacrifice to make for some added operating system efficiency. I would prefer for the vi to have a flag that would allow the user to choose to wait longer for the disconnect to really complete or simply mark the port to be disconnected, with the caution that some additional time must elapse for the local port to be reused with the same network address.

Justin

---

I do think that there might be an additional problem with the Telnet VIs but haven't them installed at the moment to look where it might go wrong. The Telnet Close might actually only close the telnet session and not the TCP/IP session for one reason or another.

However the specific behaviour of the close connection itself is dictated by the socket library, in this case the BSD sockets which is the defacto standard for TCP/IP socket interfaces and since Windows implements the BSD socket behaviour in most aspects (Winsock originally was simply copied over from the BSD socket implementation source code) it also applies to Windows TCP/IP applications.

An implementation as you suggest it might under certain circumstances block indefinitely on executing a close for a socket which has been stuck in the disconnection phase. I do believe that some socket implementations might implement some timeout after which a stuck socket is discarded anyhow, but that might not be a default behaviour. Even for normal connections the disconnection phase could take anywhere from less than a millisecond when the remote side is on the same local network or even in the same computer, to several seconds or longer if the remote side is over the internet and especially if behind a slow dialup connection. Since it is not usual to select a specific local port however, this is normally not a problem at all.

Rolf Kalbermatter

Message Edited by rolfk on 06-30-2005 10:57 AM