AnsweredAssumed Answered

MQX 4.2 Kinetis websocket behavior

Question asked by FRED WEDEMEIER on Aug 4, 2015
Latest reply on Aug 12, 2015 by Radek Sestak

I'm intending to use websockets to pass rather long JSON strings to javascript in a browser app. I have things cobbled together and functioning, but it's not a production-ready solution:

-The browser app opens a web socket and sends a message indicating the type of response it is requesting.

- The server message-receive callback builds the response JSON string and attempts to return it via WS_send().

- If the code builds and returns the response from a single large buffer things work as expected.

 

Given the limited amount of RAM in the K parts, the production code can't afford to statically allocate a large message buffer, allocate it on a stack frame, and certainly will not malloc/free large buffers on a system that needs to remain up and running for unlimited durations.  The attempted solution was to allocate a small buffer, then build the response in chunks and use the FIN flag to indicate end of message as specified by the RTCS user  manual. This completely bolluxes the works:

- WS_send() operations are not sent out the wire until the message-receive callback returns.

- It appears all the chunks are queued and are sent out the wire back to back when the callback returns.

- Re-use of the small buffer for each WS_send() causes the content of each chunk to be the content of the last chunk.

 

So I would first suggest the behavior of the websocket code needs much better documentation since there's no hint of this in the RTCS 4.2 manual.

 

Questions:

 

1. Is there some means to correctly issue multiple WS_send() operations in the context of a message-receive callback?

 

2. Assuming "No," can multiple WS_send() operations with a small buffer be made to work even outside the context of a message-receive callback? The potential issue I see is the non-blocking behavior of the WS_send() operations inside the receive callback. If the behavior is non-blocking outside the callback, re-writing the buffer will most likely muck up the data sent in earlier calls.

Outcomes