Problems re-establishing TCP communication

[JaySisko]

I have two computers with 3 ethernet ports each, connected to each other via one of their ethernet ports (each with a static IP address). Computer 1 will open a TCP connection, while computer 2 does a 'TCP listen'. After the connection is made and data get shuffled from 1 to 2 via TCP writes & reads, I perform a TCP close connection when the VI is stopped. My problem is that when I try to run the VIs again shortly after, computer 1 gives me a "...network address already in use" error, and I have to wait a few minutes to be able to reconnect again. Is this a Labview issue (using LV 7.1.1) or is it windows not releasing that particular IP address for a few minutes? If the connection is broken between the 2 computers for whatever reason, I need to be able to reconnect as soon as possible. Has anybody had similar problems using TCP?

[ned]

Are you stopping the VI on both computers, or just computer 1? When you open the connection on computer 1 (the non-listening end), are you specifying the local port, or allowing the operating system to choose? You should be allowing the operating system to choose, because the operating system will hold a specific IP/port combination for an amount of time after closing the connection (this is part of the TCP specification) which could cause the error you're seeing.

[Rolf Kalbermatter]

QUOTE (ned @ Mar 28 2009, 02:01 PM)

Are you stopping the VI on both computers, or just computer 1? When you open the connection on computer 1 (the non-listening end), are you specifying the local port, or allowing the operating system to choose? You should be allowing the operating system to choose, because the operating system will hold a specific IP/port combination for an amount of time after closing the connection (this is part of the TCP specification) which could cause the error you're seeing.

Ben is right. No need to request the TCP Open to open a specific local port at all. Just leave the local port input empty, which tells LabVIEW to let the OS select whatever port it can. For a client (No TCP Listen used) only the remote port is normally important, except with some strange protocols sometimes.

Rolf Kalbermatter

[Mark Yedinak]

QUOTE (rolfk @ Mar 29 2009, 02:31 AM)

Ben is right. No need to request the TCP Open to open a specific local port at all. Just leave the local port input empty, which tells LabVIEW to let the OS select whatever port it can. For a client (No TCP Listen used) only the remote port is normally important, except with some strange protocols sometimes.

Rolf Kalbermatter

The LPR protocol as defined by RFC 1179 is one such protocol. According to the RFC the source port must be between port 721 and 731 inclusively. This particular aspect of the RFC is ignored by virtually every implementation I have seen and I have yet to find a LPR server that cares about the source port but it is in the RFC.

[JaySisko]

QUOTE (rolfk @ Mar 29 2009, 03:31 AM)

Ben is right. No need to request the TCP Open to open a specific local port at all. Just leave the local port input empty, which tells LabVIEW to let the OS select whatever port it can. For a client (No TCP Listen used) only the remote port is normally important, except with some strange protocols sometimes.

Rolf Kalbermatter

Thanks, it looks like that was the problem, I was setting the value for the local port on the "TCP Open Connection" VI. Letting the OS find and use an available port works great. You all have a great week!

JaySisko

[Rolf Kalbermatter]

QUOTE (Mark Yedinak @ Mar 30 2009, 04:35 PM)

The LPR protocol as defined by RFC 1179 is one such protocol. According to the RFC the source port must be between port 721 and 731 inclusively. This particular aspect of the RFC is ignored by virtually every implementation I have seen and I have yet to find a LPR server that cares about the source port but it is in the RFC.

This would seem mostly a useless restriction to me unless for security reasons, when you want to restrict the firewall passthrough both on the outgoing and incoming side.

Rolf Kalbermatter