1

What I'm doing

I'm implementing a websocket server on a stellaris board as the title says. At the moment I'm able to establish connection to the client and send a few frames.

The way I'm implementing the websocket

The way I'm developing it is something like a master slave communication. Whenever the client sends a string, the server decodes it and then answers. At the moment I'm simply responding to a character 'e', which is designed to be just a counter. The thing is that I implemented the websocket on the client side to send 'e' whenever it receives a message and then displays the message on the page.

The problem

The problem is that it does about 15 transactions and then I can see the communication being re-transmitted from and to the stellaris board and then the communication closes. After the connection closes I noticed that that I can't access any other page on the board. It simply doesn't respond anymore.

My assumptions of what may be causing it

This lead me to believe that the transactions are being too fast and there may be an implementation bug, lwIP bug or hardware bug (I'm using the enet_io example as base).

My assumptions on how to fix it

After seeing this I can imagine that what I need is to control the string being sent to the microcontroller so that it sends once a second, or maybe even less, because at the moment it was doing something like 1000 transactions per second and sometimes more.

The question

So ... after my trials I still have a few questions that need to be answered. Do websockets need this kind of relationship? Where client asks and server serves? Or can I simply stream data from the server to the client as long as the connection is open? Is my supposition that slowing down my rates will work?

morcillo
  • 1,091
  • 5
  • 19
  • 51
  • 1
    Websockets doesn't require a request-response model (except for the connection establishing handshake). The server can stream data to the client without worrying about any response or request from the client. – Myst Apr 20 '17 at 02:51
  • I don't know how your code looks, but reading your question I thought I should mention that Websocekts are NOT sockets... Websockets occupy the same network layer as HTTP, FTP, SSH etc' - it's a protocol. – Myst Apr 20 '17 at 02:53
  • @Myst thank you for your answer, would you like to post it as an answer? And also I know it's not a socket. I just got curious because every single example I say worked that way and I just assumed it was supposed to work that way. I know the packet format and all, I was just having that doubt. And also why it stopped exchanging data ... I assume it's because of the speed it's being updated (I'm actually able to capture it as websockets in wireshark and display data successfully on the client's browser) until it freezes – morcillo Apr 20 '17 at 03:00
  • @Myst Also I learned that there is a bug in my version of firefox that creates two instances of a websocket and performs 2 consecutive sends from the client side each time – morcillo Apr 20 '17 at 03:02
  • I posted an answer. P.S. Am I correct to assume, from your latest comment I understand your server wasn't designed to handle concurrent clients? Are you using a Linux distro? If so, are you using an existing framework (i.e. [`libwebsockets`](https://libwebsockets.org) or [`fail.io`](http://facil.io)) or are you rolling your own? I'm just wondering why the board would spinlock (I think that's what is happening) or hang. – Myst Apr 20 '17 at 03:16

1 Answers1

1

Do websockets need this kind of relationship [request-response]? Where client asks and server serves? Or can I simply stream data from the server to the client as long as the connection is open?

The Websocket protocol doesn't require a request-response model (except for the connection establishing handshake).

The server can stream data to the client without worrying about any response or request from the client.

However, it's common practice to get a response or a ping from a client once in a while, just to know they're alive.

This allows the client to renew a connection if a message or ping fails to reach the server - otherwise the client might not notice an abnormally dropped connection (it will just assume no updates are being sent because there's no new data).

It also allows the server to know a connection is still alive even when no information is being exchanged.

Is my supposition that slowing down my rates will work?

I guess this question becomes less relevant due to the first question's answer... however, I should probably note that the web socket client (often a browser) will have limited resources and a different memory management scheme.

Browsers are easy to overwhelm with too much data because they often keep references to all the exchanges since the page was loaded (or refreshed).

This is especially true when logging events to a browser's console.

Myst
  • 18,516
  • 2
  • 45
  • 67