Switch to Enhanced Solo-Launcher Connection Technique

[PropGit]

Originally posted by @zfi in https://github.com/parallaxinc/solo/issues/460#issuecomment-642199425

I have added a second watchdog to the connection service that looks to see when we received the last port list from the Launcher or client. If we don't see the update within 10 seconds, Solo will close the current connection and re-establish a new connection to the Launcher or Client. This will appear in v1.5.0-RC-1.

[PropGit]

Originally posted by @PropGit in https://github.com/parallaxinc/solo/issues/460#issuecomment-642230070

I so badly want to get away from this polling/heartbeat thing whenever we can think clearly enough to do it.

A full Propeller 1 program may take up to 6 or so seconds to download. The port list "service" is halted during downloads... so if Solo was sitting at 4.9 seconds since it's last received message, and there's a large download the occurs right then, it may be > 12 seconds or so (in it's eyes) before it receives another port list.

Can we make Solo extend the timeout or better yet have Solo restart its internal countdown the moment a download request is sent to Launcher?

[PropGit]

Originally posted by @zfi in https://github.com/parallaxinc/solo/issues/460#issuecomment-642244726

I think we are at the place we need to be to make that change. There are at least two ways to do this. First, my preferred process is that Solo sends a ping-like message to Launcher and gets a pong-like response. Then Solo knows that we're good to go. The alternate, but more shady process is to rely on the port updates to determine that there is a valid connection.

[PropGit]

Originally posted by @PropGit in https://github.com/parallaxinc/solo/issues/460#issuecomment-642273661

This is actually possible right now (and has been before these recent versions even) by Solo sending a "hello-browser" message and Launcher sends it back a "hello-client" response with it's version number. It's perfectly acceptable in the current messaging to send a "hello-browser" at nearly any time (but would suggest not making it more frequent than 5 seconds).

We must make sure that Solo does not send a "hello-browser" message during a download request; it can resume requests after download is complete. Similarly, "hello-browser" requests during continuous terminal or graphing activity is redundant and may interfere. Maybe the rule is, if there hasn't been any message from Launcher in some amount of time, send a "hello-browser" message just to check if it's still there; otherwise, the other message activity serves as knowledge of a healthy connection.

The alternate, but more shady process is to rely on the port updates to determine that there is a valid connection.

Shady, yes... this is what we're doing already and for some reason it's not working perfectly all the time.

[PropGit]

Originally posted by @zfi in https://github.com/parallaxinc/solo/issues/460#issuecomment-642289676

The intent for the ping/pong message was to verify that we have an active web socket connection before sending a load command to the Launcher. We use it to set up the initial connection now. I would extend the use cases to do the connection validation before the load to RAM or EEPROM commands are issued. If we are in agreement on this point, I think I can remove the remaining connection watchdog timers in Solo. It will be magic.

[PropGit]

This sounds fantastic! Excellent observation/analysis.

After thinking about this further, seeing the code/technique it looks like you're preparing, and thinking of the future situations with the extension of the port-list-request in Issue #464, please consider and discuss this as a solution:

• Keep the "hello-browser" (tx) and "hello-client" (rx) step to establish Launcher communication (of course; no change)
• Note the last time-stamp of any received communication from the Launcher - it looks like that's what you're preparing/thinking
  • This means the last-launcher-comm-timestamp must be updated with every received communication, including those of type...
  • "hello-client"
  • "ui-command"
  • "port-list"
  • "serial-terminal"
• Before any Load to RAM, Load to EEPROM, Terminal, and Graph connection message is sent to Launcher, check the last-launcher-comm-timestamp.
  • If it's recent (TBD, but say within the last 12 seconds), just send the desired message as normal
  • If it's not recent, send a "hello-browser" message and wait...
  • Received a "hello-client" in return? Send the desired message
  • No "hello-client" received (within a short timeout window, perhaps 2 seconds max)? Switch to the no-launcher-detected state (ala pink message in menu bar) and display error in dialog indicating that the connection to the Launcher was lost.
  • Remove the connection watchdog timers that have plagued us

All the above is compatible with recent and current versions of Launcher and should work perfectly with future versions as well, even if that future means port-list messages are sent only when requested or when there's a detected change to the list.