Websocket library bugs

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

I am trying to use websocket library in the SDK 3.1.2 (which I believe is the latest), and finding what I think are quite frightening bugs.

To start with:

  1. It does not compile against the SDK itself: a constant from base64 lib is different, BASE64_ENC_STANDARD, should be BASE64_STANDARD.

Then there are 3 major bugs in wiced_websocket_receive:

  1. It does not attempt to free incoming TCP packets, so the application will quickly leak memory. It does not expose them to the client code either (because it tries to handle fragmentation).
  2. rx_frame->payload_length is not assigned the length of the actual received frame payload for text and binary frames, so there is no way to tell the length of the received data in the application, when the function returns. I think it's intended to be used this way, seeing how "ping" and "connection close" frames are handling it, which I assume is correct.
  3. From what I see, not all fragmentation cases are handled: the only multi-packet case handled is a single frame aligned to a packet boundary, but not when a packet contains multiple frames, or more complex fragmentation cases, because of the loop logic: when a full frame is read from a packet, the rest of the packet is ignored. For example, this one:
    1. packet 1 = frame 1, frame 2 (part 1)
    2. packet 2 = frame 2 (part 2), frame 3


Some other minor documentation issues I could spot:

  1. wiced_websocket_receive function documents a "tx_frame to send" parameter
  2. wiced_websocket_callbacks_t parameter lifetime is not documented (it's not copied and is expected to survive for the lifetime of the connection), which caused some hair-pulling.

So the question is, am I right in expecting the websocket library to be production-ready right this moment, or it's more of a beta/experimental code I should not rely on?

0 Likes
8 Replies
Anonymous
Not applicable

*crickets*

0 Likes
Anonymous
Not applicable

And 2 more!

  1. global handshake_mutex is unlocked, but not locked in wiced_websocket_close().
  2. Inside websocket_common_connect, global handshake_mutex won't be unlocked on errors, because of multiple early exits via IF_ERROR_RECORD_AND_EXIT macro.
0 Likes
Anonymous
Not applicable

I keep on finding more minor things.

  1. websocket_manager is basically unused for anything (websocket registration isn't used for any purpose).
  2. There are variables that's set and not used, like frame_control_bytes and frame_length_bytes in wiced_websocket_receive().
  3. Some other minor bugs, e.g. comparison that's always true: if ( &websocket->socket != NULL )


All of these make me conclude the library is incomplete and is not meant to be used in production.

0 Likes

You're not alone. It isn't easy finding out what's ready and what's not anymore.

0 Likes

Hi,

Yes, there is a websocket library in the SDK 3.1.2 release but it is not supported yet. There is no snippet sample application as well. On next WICED SDK release, websocket will be supported and there will be a snippet sample application as well. There is an intention to support splitting across multiple frames on future releases.


Seyhan

0 Likes
Anonymous
Not applicable

If you don't mind me asking, why was it released if it's not supported? What's the status of SDK 3.1.2 in general? Is it a beta?

0 Likes

We will look into what happened here, we will be more careful in future releases.

0 Likes
Anonymous
Not applicable

Hi gangi,

Just a few suggestions.

Do you consider time based stable release for the SDK?

If a new feature take time to development, that's fine.

But people still need bug fix for current SDK.

For example, the sdk-3.1.2 needs a lot of fixes (a lot of patches available

on the forum). There are also some bugs pointed out by alex on

the forum but does not get fix. I think it's important to get bug fix first.

It would be helpful if you can release time based bug fix release.

Regards.

0 Likes