nx_websocket_client_data_process: Return true opcode with fin bit

[elrafoon]

Hello,

maybe this needs even better solution, but according to my knowledge of netxduo websocket client implementation, currently there is no way to properly discriminate:

• first text/binary frame packet, which can further be split into multiple tcp packets
• continuation packets, where each can be split into multiple tcp packets
• last continuation packet, again split into multiple tcp packets

This small patch is about giving the caller at least the same information as nx_websocket_client_data_process() function has.

But caller still needs to take nx_websocket_client_frame_data_received and nx_websocket_client_frame_data_length into account to detect the last tcp packet of last continuation frame.

If someone can proprose better solution, I'm willing to look into it.

[TrumsZ]

Hi elrafoon,

The application layer which utilizes the WebSocket module could apply own mechanism in application data to determine how to handle possible small split tcp packets after calling the API function nx_websocket_client_receive. Since WebSocket does not restrict the number of application layer frames inside one complete WebSocket frame, providing the FIN bit information to the application is not equivalent to delivering the information to the application that an application layer frame is completely received or not. You may reference the MQTT client https://github.com/eclipse-threadx/netxduo/blob/master/addons/mqtt/nxd_mqtt_client.c to see how MQTT utilizes the WebSocket module.

[elrafoon]

Of course, if application protocol provides its own headers to delimit invididual messages, then the FIN bit information and distinguishing TEXT/BINARY from CONTINUATION frames is not needed.

But in my case application protocol doesn't do any framing on its own, it doesn't provide any headers to allow application-layer packet delimiting. It's an OCPP 1.6 protocol, see here. To sum it, one JSON payload is transferred in one websocket frame, without any headers or delimiters. It's world-wide standard for EV charging backend communication.

Without applying this patch, how should I proceed in such case?

[TrumsZ]

Hello elrafoon, do you think it is feasible to use the curly braces as the judgement conditions for the application layer to catch the beginning and end of a JSON frame?

[elrafoon]

It's a heuristic, not exact method. JSON payload can be malformed. It's not generally applicable. Next time there would be different application protocol and similar solution won't work.

Since netxduo can't assemble whole websocket frame (due to RAM limitations in embedded systems) and only then pass it to the caller, caller must have some way to reliably identify the NX_PACKET it is dealing with. Why would you hide the information available from the caller?

[TrumsZ]

Hello elrafoon, the initial purpose of NetxDuo WebSocket module is for NetxDuo MQTT client to utilize, and the design targets to simplify the caller's work through caring about the received data only without caring about any WebSocket specific details. So far, the WebSocket design cannot satisfy the caller without frame boundary defining ability. Your recommendation will be taken into consideration for the future design; so far, there is no plan on improving this.