Jump to content

TCP vi problems


Recommended Posts

Hi, my problem is this. The vi tcp open connection keep opening connections on all the ports, incrementing the port with every run of the loop it's in, until it runs out of ports and claims that the "network adress is currently in use". I've used this vi, and it's "family" for some time, in the same configuration, and this problem never occured before. Any suggestions would be greatly apreciated.

Link to comment

QUOTE (n00bzor @ Apr 29 2009, 02:04 PM)

Hi, my problem is this. The vi tcp open connection keep opening connections on all the ports, incrementing the port with every run of the loop it's in, until it runs out of ports and claims that the "network adress is currently in use". I've used this vi, and it's "family" for some time, in the same configuration, and this problem never occured before. Any suggestions would be greatly apreciated.

Can you post the code so we can see how you are calling TCP Open Connection.vi

Link to comment

QUOTE (santi122 @ Apr 30 2009, 01:28 AM)

Hi n00bzor,

what about trying it like this way ??

You can even keep the error wire wired to the TCP Close function. All Close functions in LabVIEW "should" (and usually do) close the refnum they are given, independant of the error in. There were a few LabVIEW versions in the past where one or the other did have a bug and did not properly do so but that was usually fixed very quickly.

Rolf Kalbermatter

Link to comment

QUOTE (santi122 @ Apr 30 2009, 09:28 AM)

Hey, sorry for the late response. Tried it your way, it's still not working. Here's how i'm doing it :

Problem is that for about 3 months i worked with it this way, opening around 10 connections on 10 ports, on the same host and did not encounter this problem.

Only thing i can think about now is that installing SP3 for Win XP totally ruined SOMETHING. Don't really know what.

QUOTE (mesmith @ Apr 30 2009, 01:12 AM)

If you're running out of ports (I'm assuming the "local port" control is unwired), then it most likely means none of your connections are getting closed properly or you're really running out of local ports. A TCP connection that reads from a port won't release its port immediately upon a close - it goes into FIN_WAIT and TIME_WAIT states to allow for packets wandering around the net and such to arrive. Opening a connection for write only allows it to release upon close (or as soon as all data is sent).

So, if you're looping thru connections at fast rate, then you might actually run out before the ports before they exit the WAIT states and become available again. With that said, I can't imagine how one would run out of local ports in any kind of system - you should have at least hundreds available.

Assuming you're on a windows machine, run netstat from the command window and see what ports are in use when you get this error.

Mark

Hi,

Well, you're totally right on that one. Ports do remain in TIME_WAIT and CLOSE for about two minutes, and i think that might really be the problem. I do have thousands of ports available, however, it runs through in a matter of seconds. Using the local port parameter only results in the program running once then shutting down due to the "address in use" errorr. Like i said before, using this configuration worked perfectly before. Any ideas on how i can get windows xp to close inactive, or better yet, ports in time_wait faster?

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.