We have some customers who would like to be able to use failover internet connections (mostly 4GB LTE, but could be wired) because the ISP in their areas aren't super reliable.

The problem is that SSH is a TCP based protocol and results ATE being disconnected when the IP external changes due connection failover.

Does anyone have any experience in this area?

I found Mosh (mobile shell) . It might be a good solution, but wanted to solicit some feedback if possible.

When Frank brought up a variation of this issue a few months ago, I gave some thought to trying to implement a scheme whereby the disconnected session on the server side got suspended, allowing the ATE client to reestablish a connection to. But the number of complications seemed to overwhelm the idea.

I hadn't seen Mosh then, but at first glance, it seems definitely worth some investigation. So thanks for digging that up.

I'll try to take a look at it over the weekend and report back next week.

Thanks

Although Mosh looks like a very nice development, it appears to have design conflict with the ATE/AUI command sequences...

That's all well and good if the end goal is simply to paint a text screen that ends up looking like it was supposed to (never mind the sequence of how it was actually drawn). To do that, the Mosh protocol is intimately bound up with terminal emulation logic. But I don't see how that can be compatible with the ATE/AUI command sequences (like those used with AUI_CONTROL, XTREE, etc.), which are not part of any emulation, and are opaque to the protocol. Even if we could trick the protocol into thinking the the command payloads were actually just screen text, ATE still needs to receive it in the original byte sequence.

In the other direction, the responses sent back from ATE to the server are probably compatible with Mosh, since they are effectively keystrokes, which Mosh will almost certainly have to deliver to the server in sequence.

But I don't see how the commands from the server to ATE are going to work, without devising some alternate channel to send them unbeknownst to Mosh. Which might not be any simpler that the original idea of suspending the disconnected process and figuring out how to reconnect it.

Definitely more navel-gazing required.

This is all built into the standard dtach program for Linux and works perfectly with Ashell except again, it doesn't work with ATE things.

We had one customer that had forgotten what logging in and out of the server meant after 2 years! They would just close their laptops and open them again at home and carry on.

The GUI stuff definitely complicates the problem.

Essentially we'd need to upgrade the screen tracking system to include all the GUI controls, so that when you reattached, the program could just do a full screen restore operation.

For simple controls like buttons, that may not be too difficult. But for complex ones like XTREE/XTEXT, it would be very difficult, in the event of a lost connection, to know whether the ATE client had a complete copy of the control or not. If it did, then a user like the one you describe may be in the middle of some local data entry operation on the client side and expect to continue it after closing the laptop and taking the tube home. But if it was actually a network failure, and it occurred after the server sent the XTREE setup data, but before the client had successfully received it all, then we really need some kind of reset/retransmit operation.

Most of the demand for this feature is related to network failure, as opposed to the customer type you describe. For him/her, maybe some kind of special "suspend" signal could be implemented. But for the network failure case, we really would need some kind of automated resync, which gets kind of complicated with these complex heterogeneous controls.

Also, for the case Stephen describes where the network is unreliable, even if they could reattach to the disconnected session, they'd get annoyed by having to do it manually. What they really want is something more like Mosh which would just automatically (and without any login fuss) reconnect.

"THAT'S IT!!"

Mosh wasn't the solution for IP address failover for ATE, but maybe MultiPath TCP is.

It doesn't target save/restoring GUI controls, but it could benefit users roaming between wifi, mobile, plugging in ethernet.

It's in the Linux Kernel, but not sure if Windows is going to support it.

If running a Linux kernel on both sides that supports it, services (like SSH) that would normally use traditional TCP use MPTCP instead. If it is implemented in Windows, perhaps the same will take place.