TCP Create Listener - Port busy

[sofarocker23]

Hello,

We are using the TCP function palette to create a data socket connection on a SOM9651. We do communicate with an android application as client. 

The problem we are facing, if the andorid application connects multiple times - the function "TCP Create Listener" ends up with an error. The error code is 60 - "TCP Create Listener in Websocket1_SOM.vi->PP4_RT_v1.vi".

From my understanding the port is already or still in use. We use TCP Close Connection in Labview, but the port seems to be busy anyway. The problem is easier to handle if the Android application closes the socket. If the android application fails to close the socket we cannot reconnect because the socket seems to be busy.

Is there any possibilty to free the port before trying to create a new listener?

kind regards

Christof 

[BradM]

Hi sofarocker23,

I think you're falling victim to the ol' TIME_WAIT state of the TCP connection state machine. You can verify by popping open a console on the target and take a look at the output of netstat -atn to see what's going on with the ports (run netstat -h for usage details).

Also, see http://digital.ni.com/public.nsf/allkb/119D334B8B78732E862574E1006D1839, and there are many good resources out there on the internet as to the reasoning behind the TCP TIME_WAIT state.

[sofarocker23]

Hi BradM,

thanks for you reply, I think you are right. 

The best way is to work around is to change the port in case of fast repeating requests. Trying to adjust TCP WAIT TIME doesnt seem to be very effective.

kind regards

Christof 

[BradM]

sofarocker23,

There are two approaches that I can think of (and one additional one that I'm not going to recommend) to solve this issue.

You can change a part of the four bits of information used to define a connection (client IP, client port, server IP, or server port), which I would recommend looking into ways to have the client open a new, different port for each connection (or at least wait a few minutes from closing a connection from when you recycle that client port).

The other method would be to restructure your server code to keep the listening port open and accepting connections. I have to admit, I've not tried to create this kind of an application in LabVIEW G, but it should be fairly straight-forward, and from a quick read, it looks like there's a suitable example in the shipping Example Finder in LabVIEW