Websockets client!

So, guys, I’m sharing my websockets client port!

There is still not implemented security, and handshake now generating with static key. Also there is no checking handshake on receiving from server.

But it works!

If anyone can make base64 encode and decoding of received answer on hanshake - it will be great!

7 Likes

Whoa, nice! Yay for streaming!

1 Like

Looks great !!
Now that Node.js is so popular.

Still If you could provide a Server example code in your Github to start with it, will be awesome.

:smile:

I’m using this client with spacebrew port, but i’m not planning to share it. So you can just create websocket server on Node.js and connect to it by easy steps provided in manual of node.js https://www.npmjs.org/package/ws

And what is it good for? Spark has already support for TCP + UDP client. This library does only TCP and adds some bloat like base64 encoding/decoding. TCP is useless for realtime control like DirectX joystick/gamepad + RC helicopter (even with NoDelay flag). Base64 adds another level of latency and overhead without any level of protection.

Right now I use C# .NET Socket configured as UDP datagram comm server (broadcast, no need to get IP address from Spark). It sends just 3 bytes (X, Y, Z) when I move with joystick axis. The UDP client on Spark does a good job for this (TCP is ok too, but it’s buffered).

It’s nice everyone is writing their own libraries with their own coding style and sharing it. I could write a lot of libraries for plethora of tasks and use classes and OOP and fluent, etc. But the space for actual code on Spark Core is so low, that it defeats the purpose of library as reusable OOP component.

Well, a lot’s of using for now of websockets. I’m planning to make for myself control system with lot of leds and other devices connected to node.js server, and i want to control this all things crossplatform. There is no better way than go thru browsers. What technologies are supported by browsers? Websockets!

Ahh, so you plan to communicate with Spark Core directly from web browser? Revealing the IP address and Spark Core commands in client side code making it a potential security hole?

I have worked with ExtJS (frontend) + Python (backend) on NCLab.com and even if it has a full desktop IDE including realtime WebGL support, everything is securely processed on a backend.

I would choose Akka or Netty for serverside communication instead of Node.js. For example Node.js does not have access to other IO and devices connected to a PC. I see it as a Javascript sandbox for simple messaging.

EDIT: or SuperSocket for C#/Mono: http://www.supersocket.net/

no, i’m planning to communicate with node.js between connected things, it’s already working for me - i can easily invoke functions on Spark from almost any browser with Node.js between it, even in android browser

Node.js have access to other IO thru modules, which can contain C++ objects, i’ve already created node module for Beaglebone Black to drive WS2812 directly from Node.JS

Javascript sandbox for simple messaging - correct :slight_smile:

2 Likes

Thanks for information about IO modules. Didn’t know about this feature. I’m used to C# (for Windows specific features) or Java (for multiplatform features), which allows me to directly use OS specific features like display OSD (OnScreenDisplay) or connect with gamepad. Maybe I could make some C# Windows backend for your library. I plan to screenshot a 160x120 box around mouse cursor at specific intervals and send it as UDP byte array to Spark Core and then render it on Digole OLED (256 color, 256k is just in my dreams) using hardware SPI. But only time will show how much FPS can I get for my wireless display :slight_smile:

1 Like

Well I just loved the idea of using Websockets in SparkCore… Real Time for the Win !
I didn’t know SpaceBrew… its just awesome !! Thanks for that.

3 Likes

Has SparkCore Team or someone else have had any improvements in the WebSockets department ?
I see @ekbduffy managed to port the arduino web socket client library with some faults.

But have anyone made any other goods on this ? Like socket.io support from node.js or something like that ?
I know SparkCore cloud will soon have events support… but this will only publish data to SparkCore Cloud and then Cloud will POST to somewhere else… which will result in slow communication.

@ekbduffy Is there a way to send parameters to a specific event using your library ? I see example only shows client.send(“Hello World!”); but it doesn’t specify the event name.

1 Like

You are always can send JSON:)

This is part of code, where i’m using this library:

bool send(char *name, char *type, char *value){
  const char *m1 = "{\"message\":{\"clientName\":\"",
              *m2 = "\",\"name\":\"",
              *m3 = "\",\"type\":\"",
              *m4 = "\",\"value\":\"",
              *m5 = "\"}}";
  int len = strlen(m1)+strlen(m2)+strlen(m3)+strlen(m4)+strlen(m5)+strlen(m_sClientName)+strlen(name)+strlen(type)+strlen(value);
  char b[len+1];
  strcpy(b, m1);
  strcat(b, m_sClientName);
  strcat(b, m2);
  strcat(b, name);
  strcat(b, m3);
  strcat(b, type);
  strcat(b, m4);
  strcat(b, value);
  strcat(b, m5);
  client.send(b);
}
1 Like

The problem of library is not working base64encode. Handshake isn’t checking. Spark is always trusting them. Possible security hole.

Just to check, you mean possible security issue on your core websockets client library yes? :slight_smile:

No i mean that there is possible security issue in communications without Handshake checking. But i’m not shure how it can be used to compromise communications.

@ekbduffy, I am trying to get Spacebrew going with my Spark Cores too.

I am currently trying your library:


and I understand the bit on the handshaking which is currently unsupported.

Regardless, I managed to initialize a connection a Core to my own Spacebrew server, but I seem unable to register the Spark Core as a publisher/subscriber over at my Spacebrew admin page using client.send(), via a JSON string (which is then converted to a char array before sending) .

I’m following the Spacebrew Client API format for the JSON (similar to how you have been doing it by either concatenating Strings or char arrays), but nothing shows up.

Were you able to get your Spark Cores as publishers/subscribers on your Spacebrew server?

Hello, @chuank, i’ve fixed working of websockets library :smile:
So example code is working now:)

Many thanks @ekbduffy.

I figured out how to get your websocket port going with the Spark, but thanks for posting the updated code to confirm how it should be used. :smile:

I’m in the process of integrating the Spacebrew Arduino library from the LAB folks, and have been able to easily set up the Spacebrew publishers + subscribers.

There is a very strange issue that I wonder if you have encountered:

Sending data out of instantiated publishers cause the Spark to hang. I have a simple test button circuit that sends a boolean output to the publishing stream, but after a few toggles of the button, the Spark Core will always lock up. Coolterm was able to trace the JSON output message, but everything locks up after that point.

Interestingly, I am also unable to upload new firmware, unless i do a factory reset - the solid magenta issue leads me to believe (after reading other threads on this issue) that the TCP websocket connection is stifling all OTA updates and preventing any firmware uploads to occur. Have you come across this situation in your tests with spacebrew+spark, and how did you deal with this?

(Subscribers work well, my Spark is able to listen to incoming data streams from Spacebrew Admin with no issue).

1 Like

I’ve already ported code from LAB to Spark, but it’s a little buggy.

Never got stuck spark on correct publishing. During tests faced this on wrong types passing into send function. And still can get this issue on loosing connection to server.

And I never faced any issue with upload new firmware, because i’m using local usb flashing :smile:

So, let’s show both of ours code to find differences? :slight_smile:
Here is my one https://github.com/ekbduffy/spark_spacebrew :slight_smile:

Here’s mine. Not terribly different I’m guessing from yours, but worth a check if you’re interested:

Adding a delay in setup() to allow Spark.process() to run fixed the issue on firmware uploads. I get a feeling, though, that this is probably symptomatic of other bugs elsewhere in my code – I occasionally got hard-fault SOS codes while making uploads before doing this.

Been drilling down further into LAB’s spacebrew-arduino library, and here’s are my notes:

The spacebrew server pings are providing the biggest hints for me in finding the root cause. I set up my spacebrew server to ping at default 1 second intervals. Upon startup of the Spark core, the websocket (TCPClient) correctly responds to the server’s ping opcode without issue, and sends a pong opcode in response (sidenote: I do not understand why the library sends a 0x8A byte, given that the websocket specification mentions 0x0A – and 0x0A does not work).

Most critically, when the ping/pongs are going nicely, I’ll send a spacebrew JSON message out from my Spark Core. This works very intermittently, and works only when I send the data out very sporadically. Most of the time, it causes my Spark Core to cease serial output from all debug points in my WebSocketClient::monitor function. About ten seconds later, the Spark Core resumes operation (cloud connection still good, TCPClient (websocket) connection to my spacebrew server still allegedly good), but the pings from my spacebrew server are no longer reaching the spark core.

I am testing using boolean and range data types to my spacebrew server. Event-triggered sends work, but not streamed data (it hangs up after the first/second send).

Whenever these hangs happen, my spacebrew admin page subsequently drops the Spark Core from the list of publishers/subscribers in it’s next refresh cycle.

To me, it’s either:

  1. my spacebrew server received malformed websocket data, causing a panic on the spacebrew end? Thing is, I did not notice anything odd in my spacebrew logs.
  2. could there have been a bug in the spacebrew server code, or just some incompatibilities in the websocket library that’s messing up the communication?

The still-impressive spark core and the easy-to-use (and jam) spacebrew interface is what made me want to attempt integrating these two together, but it’s been quite frustrating. It’s great to see someone else in the community trying this :slight_smile:

(and yes, I am definitely moving into local USB flashing as I’ve pretty much had it with the long waits between each test)

1 Like