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:
- 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:
- 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).
- 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.
- 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:
- packet 1 = frame 1, frame 2 (part 1)
- packet 2 = frame 2 (part 2), frame 3
Some other minor documentation issues I could spot:
- wiced_websocket_receive function documents a "tx_frame to send" parameter
- 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?
