Yet Another TCP Reconnection Issue

[Ehouarn]

Well, I've read a bit about reconnection issues basically when using TCP in LabVIEW and the fact I need to wait about 60 secs before the connection is actually close.

Is there any way to close it...let's say... much faster?

I've read some people using listener but so far I don't need a listener in my application...so what can I do then?

I attached a very dummy example, I guess this is a very usual network stuff, I've read that I could use tcpview from sysinternal and it's console counterpart maybe I can embed a license free alternative in my application and use the console in the background to use that one.

Problem is since the PID of the process which owning the running VI is 0 and guess this is not that killable =/

[nathand]

What exactly is the problem here? Your attached VI doesn't show anything helpful, and the "Timer" loop is worse than useless because it runs as fast as possible, using as much CPU time as available, to do nothing. Also, building an increasingly large array of errors is a bad idea.

It's part of the TCP standard to have a wait for a connection to close; it ensures that stale data from an old connection doesn't accidentally get treated as new data on a new connection. This does not mean you need to wait to create a new connection, though; you just need to use a different source port. Why do you have the local port wired in TCP Open? Normally you leave that unwired, and the operating system picks an available port for you at random. Wiring the local port unnecessarily is probably the entirety of your problem.

Also, the "Abort" input to TCP Close shouldn't be wired since it's not currently used.

[Ehouarn]

---

@nathand wrote:

What exactly is the problem here? Your attached VI doesn't show anything helpful, and the "Timer" loop is worse than useless because it runs as fast as possible, using as much CPU time as available, to do nothing. Also, building an increasingly large array of errors is a bad idea.

It's part of the TCP standard to have a wait for a connection to close; it ensures that stale data from an old connection doesn't accidentally get treated as new data on a new connection. This does not mean you need to wait to create a new connection, though; you just need to use a different source port. Why do you have the local port wired in TCP Open? Normally you leave that unwired, and the operating system picks an available port for you at random. Wiring the local port unnecessarily is probably the entirety of your problem.

Also, the "Abort" input to TCP Close shouldn't be wired since it's not currently used.

---

Alright, well I was a bit in rush, I will clarify everything a bit later on. 

Right now simply put: just was looking for a workaround about this TCP limitation.

The reasons why I want to do so? Impatience cause I would like to use the same port (the situation: I'm communicating with a very dumb (not that flexible) instrument and the port is kinda fixed).

Waiting the famous 60s can be a real pain (this device does not support UDP, so no connectionless alternative so far).

And yeah agreed the VI is clunky will fix that up sooner or later.

[nathand]

The workaround is don't wire the local port. The remote port - the port on the instrument - is fixed. That's normal. The instrument should not, however, care about the port on your computer that's used to establish the connection. TCP Open has inputs for both the local and remote port, but it is almost never necessary to wire the local port.

TCP connections are defined by 4 parameters: on each end, each connection has both an address and a port. TCP doesn't allow reuse of a connection with exactly the same set of those 4 parameters within some time period after a connection is closed.

Under what situations do you need to reconnect to your instrument? Sounds like maybe you should simply be holding open the same connection to the instrument, rather than regularly reconnecting to it.