WebSockets?

Websockets is often a good choice for heavily firewalled environments where native sockets may be blocked. Also if you do not have complete control of your server environment, e.g. if you are using a cloud-hosting service with a web stack only.

I think they are considerably easy for less experienced developers too, just because HTTP is more familiar than socket programming.

A good deal of other stuff you typically need to implement in a command-and-control sceanrio such as authentication etc. can also be taken care of for you by your web-stack of choice which makes development faster.

The downside though is overhead of the HTTP stack, both in transmission sizes and processing speed if e.g. you are on a GPRS or low-fi radio network.

On a micro-controller if speed and performance were most important I would probably use net sockets. Example, I have in mind to build a voice-control system with a Pi running Google voice recognition as the central server and Picos as controllers. For that purpose, speed is probably pretty important - if I say "turn the lights on" I just want them to come on as quickly as possible.

On the other hand if I were already using HTTP comms to this central server in the project and it didn't need to be as close to realtime as possible, then web sockets would be a good choice.

The public server is a nice idea, but I'm not sure there's enough headroom in the client for an extra control layer to be attractive, nor enough shared purpose about what people may want to do with it. There're quite a lot of such command and control cloud-based services around which you can opt into if you want that. Perhaps an Espruino client for one or more of those would be a better approach.

Might be fun to run up a simple stats engine though which people could opt into and use it to drive a map and some numbers. I sort of doubt it would get much take-up though - although you could make it the default example on the http page which might help!

I was thinking something along the lines of a web-hosted version of the Web IDE that actually just gave you access to the Espruino console (as if it was plugged in). With access to the console you could basically do whatever you want - and it's not really adding much in the way of overhead to Espruino itself.

Not to start a religious war, but it seems to me that for IoT messaging the MQTT protocol is better suited and very popular. It has features such as persistent messages and last-will messages that can help with sensors that only periodically report values.
Where websockets are interesting is for web browsers to connect to an espruino and get real-time updates, i.e., the use-case that @JumJum seems to be after.

I like how things go in circles over times... decades...

@tve is just right: no what-so-ever war helps us to find 'the' solution. It all depends: weighing the context / constraints / resources across the whole life cycle and balancing with the (intentionally selected) opportunity costs have to be the guideline.

In order to still stay flexible, a good modularization and layering / api choices allow adjustments for the better while still underway in building without essential consequences (...without having to start over).

@tve, you exactly hit my point.
I will have a lot of data from several sensors. This data is used to create charts. Charts are updated, whenever new data is comin in. This is something, often used in controlrooms.
With websockets the amount of data to be send are only a few bytes.
Having a cloud in the background would go over the top. And I would loose some control.

@sameh.hady thanks for writing a ws module :) this will come in handy with node-webkit. Someone can create a GUI and a ws server in node-webkit and you'll have a nice "dashboard" interface that can update in real time :)

Anyways, in the past I created a node.js ws server, but it would crash out of no where. Is there anything that anyone can do to catch the exception and keep the node.js ws server from crashing or detect a crash and re-initialize the node.js ws server?

Thx @d0773d, I had a previous issue before with nodejs crashing and after doing lots of research for error handling etc it didn't actually work as I wanted.

Still I found this lovely piece of code that actually prevented nodejs from crashing whatever happens.

process.on('uncaughtException', function (err) {
  console.error(err);
  console.log("Node NOT Exiting...");
});

Hope it would help.

@sameh.hady thanks for the help. I will surely give that a try over the weekend and respond back with my results.

In the mean time, do you happen to know if I will need to instantiate the node.js ws server again even though the uncaughtException is captured and node.js does NOT crash?

if the exception is related to the ws server then yes you will need to instantiate the server again, if it is not related then everything should be fine.

Question is, why would the ws server crash? this shouldn't happen unless you have an issue in the code. So i recommend you find and fix than just catch

remember, if the ws server crashed and restarted you will loose all your clients sessions and the clients will act as if they are rejoining again with new session.

@sameh.hady nodejs ws server has been up for about 2 days without crashing :)

Great @d0773dm glad you sorted it out :)

WebSocket Server support now works! http://forum.espruino.com/conversations/­278902/#comment12674947

@sameh.hady is there a reason that the ws library wraps everything up as JSON? It seems that at least on the client end (as a browser) you don't have to.

Just in case anyone is interested on secure webSockets I have a rough implementation on GitHub (wss.js) based on the examples in this thread and the current ws module. It works with my server, but I would like to make some more testing and try to do the server part before asking for a pull request.

By the way, I used a new module, wss.js, instead of modifying the current ws.js file since SSL/TLS is not available on all Espruino boards. But I can accept sugestions.

Thanks! It seems a shame to have a duplicate of what's basically the same module though.

I wonder whether it'd make more sense to just allow the existing WebSocket library to be used easily with a connection that was already established? After all, that's what createServer ends up doing, and actually you don't really want to have to pass all the TLS connection parameters through - as mentioned in the HTTPS thread, it turns out you might not want to specify some of those parameters at all.

I'd like to use the wss for my client on ESP8266, but the require( 'tls' ) module can not be found...

tls is for the secure sockets, which won't fit into ESP8266.

Looks like it should still work as long as you don't use the code in such a way that you're asking it to make a secure connection? But honestly the espruino-provided websocket code should work pretty well now?

If I try connecting to wss://myserver.com:8822:

var ws = require( 'ws' )( 'beta.mozaiq.io', { port:8822 } )

I get

console.log( ws.lastData )
HTTP/1.1 400 Bad Request
Server: nginx/1.10.1
Date: Mon, 13 Feb 2017 11:35:49 GMT
Content-Type: text/html
Content-Length: 271
Connection: close
400 The plain HTTP request was sent to HTTPS port

In the chrome ws-client the connection over wss:// is working.

I have another SSL-free ws-endpoint on 8827 on my server, and it's working just fine in ESP.

Well, since ESP8266 doesn't do SSL with Espruino it's hardly surprising it's complaining.

If you had an Espruino WiFi or had an Espruino Pico with ESP8266 connected then SSL would work.

I have a NodeMCU dev board with ESP8266 MOD (?) chip on it. Is it compatible with EspruinoWIFI?

Is it compatible with EspruinoWIFI?

No. Espruino WiFi is a board itself - it's for an STM32 and a ESP8266 on it, so has more memory available for stuff like TLS.