> On Jul 2, 2021, at 9:07 PM, Dmitry Karpov via curl-library > <curl-library@cool.haxx.se> wrote: > >> could libcurl wait for all the fragmented messages to arrive, then concat >> them and serve the completed message to the calling application? > > I don't think it is possible in all the cases. WebSocket text/data messages > can have 64-bit length, so it is just not possible to assemble large messages. > I implemented WebSocket protocol in some C++ curl-based client and I used the > following approach: > > 1. Notify client that some WS not control message (i.e. text/data) has > arrived. > 2. In the notification callback, Client either provides a buffer to store the > message (can be useful for short messages) or data writing callback to store > large messages (where data concatenation is not feasible). > - If provided buffer is too small to hold the message, then we need to > handle it as WebSocket protocol prescribes - close WS connection with 1009 > 'Buffer too small' error code. > > 3. I also provided a special callback for incoming control messages (i.e. > Ping) while large data messages are being received, so client can handle > multiple messages (one large data and multiple control messages at the same > time) at the same time.
Curl will have to allocate a buffer for each frame’s data anyway; maybe just give that buffer to the callback? Then allow the caller either to assume ownership of it, or free the buffer after the callback is done. > WebSocket protocol is very specific about how and when WS connection should > handle certain errors, and which status codes should be used in different > connection closure cases, so sometimes some specific transport errors (like > Tls handshake errors) should be explicitly handled and reported as WS > connection closures with specific status codes (i.e. 1015 'TLS handshake > failure'). 1015 is an interesting one … I guess it’s for a STARTTLS-type workflow where the TLS rides on WebSocket? Regarding connection closures, WebSocket seems to follow SCTP’s model; that may be useful prior art to consult. -F ------------------------------------------------------------------- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
