Port saturation?

[CraigGraham]

I've got to go fix a project I'm unfamiliar with, and I'm looking through the code to get pointers.

It's a PC talking to a cFP unit via the TCP VIs. There's also the data publishing stuff and direct Fieldpoint IO point reads being used at the same time.

Symptoms are that after an unspecified length of time, the PC loses comms with the cFP unit. There's two places the reported error can come from- first is from a Fieldpoint network read function, second is if the TCP bit fails to establish a connection. I suspect the latter.

The way this is written, the TCP stuff opens a connection, sends a few bytes, gets a few bytes back then closes the connection again- then immediately repeats in a loop. It's in a timed loop with a 50ms tick but this isn't doing anything against the larger loop execution time. This means many connections are left in TIME_WAIT, so the obvious questions are how many ephemeral ports are available for use on cFP and what the TIME_WAIT period defaults to on cFP? Anyone know? On my XP machine, Labview's only using a couple of thousand ports, making a couple of connections a second, and the TIME_WAIT period's evidently less than the 15 minutes or so it'd take to get port exhaustion but I could imagine cFP using a smaller port range to save resources.

[Yair]

I don't know the details of how the ports are handled, but I do remember hearing about cases where the ports aren't freed fast enough if you open many ports.

In any case, the solution would be to only open the port once and only do the write-read cycle in the loop. This works perfectly well and is probably faster. To get safe comm, place the open-close part in an outer loop, but this loop should only keep running if the internal loop experienced errors.