Force Close TCP Socket?

Is there a way to force closed a TCP socket that was left open? I have a Fusion Ethernet Board and I'm using Reactor inputs with push notifications. I need to constantly be connected to receive push notifications so I can't close the socket with each command issued (unless I'm misunderstanding something with Reactor push notifications, which I'm assuming require an open socket).

In my application I'm using several boards with an ethernet connected tablet. These boards are not connected to one another nor are they networked at all, by request of the customer. They want to be able to plug in one of two identical tablets directly into any one of 4 identical Fusion boards (which I have set to a static IP). I have my application set to close the socket when exiting so, as long as I exit the application before physically disconnecting from the relay boards, I can bounce around between boards and tablets without problem. If, however, I get disconnected accidentally (or if I unplug before exiting), it can take minutes to reconnect to the relay boards unless I cycle power to them. Cycling power is not an option because of the hassle involved.

Would UDP be a better solution in this case? IF so, I might need a little guidance to get started. Also, the relay boards are already on site being installed, so I would prefer to not have a solution that requires the boards in hand, if possible. That said, I used pluggable connectors so I can easily have them shipped back to me if the ideal solution requires that I have the boards present.

 

Thanks,

Mike

T

Hi Mike,

Are the Ethernet modules Lantronix XPort(standard Ethernet) or XPort Pro(WEB-i)?

If they are Lantronix XPort then you have several options for handling connections.  Settings on the Ethernet module can be set through the module's web interface, just enter the controller's IP address into your web browser(if prompted for a password just press enter as one is not set by default). 

You can set an idle timeout on the module so if no data is communicated over a certain period of time the Ethernet module will force close the open socket.

With our standard configuration the Lantronix module acts as the server meaning your application establishes a connection to it so yoru application is the client and the module is the server.  You can set a host IP and port on the module which will cause the module to establish a connection to the application running on your tablet at boot time.  This would mean your application is the server and the Lantronix module is the client.

You can also use UDP as you suggested.  This can be confgured in the web interface as well by switching from TCP to UDP.

Let me know if any of these possible solutions sound like what you need and if so let me know if you have questions on any of them.

M

Travis,

Thanks for getting back to me. So I guess the bad news is that there is nothing I can do on the app end to force close the socket, but the good news is it can all be handled with the LANTRONIX modules, which means I can change the settings here and ship them out and have just the modules swapped out. Is that correct?

In any case, of the three courses of action, is ther one you recommend over the others? I think I would rather stick with TCP over UDP because I do not want to allow the customer to be able to plug multiple tablets into the realy board in this case. If I remember correctly, UDP does not create an exlusive socket for communications so they would be allowed to operate teh relays from mutliple computers at once. 

I think I might try the other two settins (or all three, if my assumption about UDP is incorrect) settings here to see if I have a prefernce for one over the oers. I will need more guidance in all three cases, however, as I'm not sure how to proceed with any of the options. Do you have documentation that I can follow?

Thanks,

Mike

 

M

What is the current lead time on Lantronix Ethernet modules? I have 3 here and might need to order a couple more of them today if I want to swap out the ones in the field.

P.P.S. Is it the ARP cache timeout that needs to change? I ask because the default setting of 600 seconds is consistent with wha tI've been finding--that it takes >10 minutes to reconnect wihtout cycling power.

 

T

Hi Mike,

If the socket is properly closed by the app then the board will allow another connection immediately after that.  Your code on the application needs to make a proper call on the socket to close it.  If you just close the application that is not the same thing.  What language is your application written in?

M

The application closes the socket properly when exiting. As long as I exit the app before disconnecting I can reconnect immediately. The issue is when I forget to exit before disconnecting (which I'm expecting the customer will do on a regular basis).

My application keeps the socket open for the duration of the physical connection between the operator interface and board; I have push notifications that I need to be able to receive at any time. I'm actually using an automation software called Iridium Mobile. It has custom AV drivers (TCP, HTTP, UDP, RS232) that are compatible with the NCD boards. There is a setting in the software to have it connect automatically when on and disconnect automatically when exiting, which is how I have it set up (I can also send the connect and disconnect commands via javascript from within the application, which is where I'd send a force close command if one existed). I can set it to connect only when sending, but that prohibits me from receiving push notifications. I can also change the number of reconnect attempts (1 - infinity) and the wait time for connetion and the time to wait for data, but I'm not sure if that would help at all.

T

I see, so this is a situation where the user physically connects the Ethernet cable to the board and then disconnects when done.  Honestly for something like RS 232 or USB would be a whole lot better but I assume since you arent using those options the tablet does not have those connections?

I think the best solution would be to go with UDP broadcasts on the push notifications or set a timeout on the TCP socket.  If it were me I think I would lean more towards UDP broadcasts as they are connectionless.  The module just broadcasts the data to any device listening on that particular port.

M

Thanks,

We originally proposed the project with the boards and interface on the building network, but late in the game the customer requested that they not be networked and wanted a direct 1:1 connection. That said, Ethernet was still the most appealing because of the connection distances (up to 250 feet) and low cost and availability of off-the-shelf cabling.

To be clear are you recommended mixing UDP and TCP or switching to UDP entirely? Also, am I not correct in assuming that the connectionless nature of UDP means that more than one interface could operate the boards at once? Even though the intent is that it only be a 1:1 connection, the customer has it wired so that the interface can be plugged in in multiple locations, which means that they could abuse the setup to have multiple interfaces operating the same board if I don't have one connection prioritzed over the other.

Where do I set the timeout on the TCP socket?

Also, I experminted with changing a board to UDP comms and couldn't communicate via Base Station--Base Station found it but couldn't connect. Is there a setting change required in Base station, did I not properly configure the UDP settings, or does Base Station not work with UDP? If it's the latter, I think I'd prefer to stick to TCP so I can troubleshoot in Base Station as needed.

Lastly, What is the current lead time on the Lantronix modules? As mentioned, It loooks liek I'll need to swap those out regardless of which path I take.

-Mike

T

Hi Mike,

Base Station does not support communication over UDP.  

Do you need the ability to monitor push notifications from the device as well as the ability to send commands?  If so UDP may not be a great solution and you might need to fall back to the TCP socket timeout methodoligy.  For that try settings similar to this:

 

M

I do need push notifications so I'll try the TCP timeout settings you posted. I was out Friday and we are closed today, so I'll try it Tuesday. If you don't mind, can you list which of the above parameters are changed from default (or highlight on the image above) so I don't miss anything?

Thanks,

Mike

T

Hi Mike,

I definitely should have highlighted the settings, sorry about that.

If you change these two settings the module will properly close the socket open to it after 10 seconds if no data is received or transmitted.  It would be a good idea to add a keep alive message transmission to your application that just sends a test two way command to the board every 3 seconds or so, that will ensure the socket is held open.

T

M

Awesome, thanks! I actually ping the relay board every few seconds, so that should work fine.

M

Travis,

I just had a chance to check the lantronix settings on my board and the 'On Mdm_Ctrl_In Drop' setting under 'Disconnect Mode' is set to 'NO'. Yours is set to 'YES', but it isn't highlighted as a change. Did you change that too, or is that a default setting that has changed in time? I don't recall changing that on mine (I don't even know what it is), but there is certainly an outside chance that I changed it by mistake.

Thanks,

Mike

T

Hi Mike,

You know it is definitely possible that I had to change that as well.  Can't remember off the top of my head now.  I can tell you that those settings are doing what you need so I would match everything to the settings shown in that screen shot.