microBlocks stand-alone WebThing Server operation

[Turgut Guneysu]

After the initial start of the WebThing Server and successful connection from a browser session, if the WTS is stopped and restarted the browser session is impossible to reestablish.

One has to terminate the microBlocks IDE and rerun it, restart the WTS, and then the browser sessions will work again.

While it is not too bad a thing, it is a bit cumbersome if the user is NOT familiar with this idiosyncrasy.

There is a related issue regarding the spurious data exchange leftovers in the cache. I am not consistently able to reproduce this, but once in a while when the WTS is not running or even when the microBlocks user code is not running, one receives data values to requests made from the browser sessions. If at all there is a way to flush out the browser cache somehow, via a command from the browser environment (within SNAP or BeetleBlocks or via any HTTP command ), it would be very helpful.

‌

[John Maloney]

Thanks for reporting this. Which browser are you using? How are you accessing the WTS? Are you using Snap! or pasting a URL into the browser or something else?

[Turgut Guneysu]

Browser: Chrome Version 85.0.4183.121 (Official Build) (64-bit)

WTS is accessed both from a Browser tab and from the SNAP! window. Both modes result in failure to connect.

URL entered is: localhost:6473 the first time around, which gets a good response.

Then WTS is stopped and restarted.

URL entered is: localhost:6473/properties the second time around, which gets a NO response.
(Just changing the input so the display is different and caching is avoided. Nothing to do with the problem itself.)

Here is the display info from dev mode Networks, related to /properties request:

browser window is stuck at “Waiting for localhost”.

SNAP! does not have any indication of waiting at all, other than the halo effect around the

block, which never goes away.

[John Maloney]

Thanks for these details. I’ll try to reproduce this. Many OS’s don’t release a TCP/IP port immediately, and that may be what is going on here. If that’s the case, the second attempt to start WTS on port 6473 will fail if you do it right after you’ve closed it (or quit from MicroBlocks) but would succeed if you wait a few minutes. You could open a different port right away, but then you’d need to change your Snap! code to use that new port.

[John Maloney]

I’ve confirmed this behavior. It happens on Windows, but not on MacOS. Possible clue: Windows Defender asked for permission to open the socket the first time I started the server but not the second time.

For now, at least: On Windows, once you start the MicroBlocks HTTP server, you should just leave it running. Don’t try to stop and restart it. If you do stop it, you’ll need to quit and restart MicroBlocks.

[John Maloney]

Although I don’t understand the issue with the server on Windows, I am adding the ability to specify the server port. So a possible workaround will be to run the server on a new port after stopping it. Since I think the underlying issue is a bug in Windows and there will be a workaround in the next release, I’m am marking this resolved.