search

scratchfoundation / scratch-link

Device interoperability layer for Windows and MacOS
BSD 3-Clause "New" or "Revised" License
102 stars 83 forks source link

Allow use when default port is busy #144

Open cwillisf opened 5 years ago

cwillisf commented 5 years ago

Expected Behavior

It should be possible to use Scratch Link even on a computer which is running an important service on the default port.

Actual Behavior

If the default port (currently 20110) is occupied, Scratch Link exits with an error message. See #100.

Steps to Reproduce

  1. Run something which listens on port 20110. A modified development version of Scratch Link is a good candidate.
  2. Run (another copy of) Scratch Link.
  3. Note the error message.
cwillisf commented 5 years ago

Basically this means allowing Scratch Link to run on a non-default port. The tricky part is making sure that Scratch (both Scratch Desktop and web-based Scratch) are able to find Scratch Link on that non-default port.

There are basically two options that I see, and we could do either or both.

Allow users to manually configure an alternative port.

We could add some sort of settings dialog in Scratch Link to allow the user to specify a different port. We would also add a settings dialog in Scratch so that the user can specify the same port there, allowing Scratch to find Scratch Link.

This seems pretty good except for the fact that someone comfortable with network configuration would need to copy the port number over. Also, we'd need to put some at-least-semi-persistent configuration storage into Scratch, and apart from the UI language I don't think we have anything like that right now.

Automatically use an alternative port.

It's tempting to suggest using an automatic service discovery protocol like Bonjour, Avahi, mDNS, DNS-SD, etc., but it appears that browser code cannot currently act as a client for any of these service-discovery techniques.

What we could do instead is pre-define a list of ports to try. Scratch Link would bind to the first available port on the list, and Scratch would attempt to connect to each port in the list until it finds a successful Scratch Link handshake. We'd need to scan in such a way that if Scratch "misses" Scratch Link on the first run through the list, for example because Scratch Link was still starting up, the delay until the second run-through is tolerably short.

The list could either be a hard-coded list of ports (like [20110, 42424, 12345, ...] though probably chosen more carefully) or we could just start with the default port and go up by 1 until we either find a good port or hit some limit. The latter is more or less what I'm used to from using X11 and it works well there, so I think that's what I would suggest.