Frame payloads are read in chunks using Payload.t, and the end of frame is signalled with an on_eof callback after the last chunk is provided with the on_read callback:
In Dream, I chose to treat chunks as the frames in my reader, i.e. if a frame is split into multiple chunks during reading, I just emit those chunks, and report FIN with the last chunk of the last frame. However, because the on_eof callback gets called after that last chunk, I have to cache each chunk until the reader knows whether the next callback turns out to be on_eof or not.
I chose to have the reader report FIN with the last chunk, rather than also with a separate on_eof callback, for symmetry with WebSocket writing, because the WebSocket protocol requires FIN to be provided with the last frame. Providing it after the last frame would similarly require a WebSocket writer to cache each chunk until it knew whether FIN was set by a next eof call or not.
I think it would be better to remain consistent with the WebSocket protocol and writers, and have schedule_read somehow report the last chunk in the on_read callback.
I think it's possible to get a similar effect by tracking the total number of bytes read and comparing to the length from the frame header, but I am not sure how trustworthy that is.
Frame payloads are read in chunks using
Payload.t, and the end of frame is signalled with anon_eofcallback after the last chunk is provided with theon_readcallback:https://github.com/anmonteiro/websocketaf/blob/248a2cb0dcffa51996c3ad7643577dce75d67454/lib/websocketaf.mli#L8-L12
However, the
FINbit is provided with the last frame (not after):https://github.com/anmonteiro/websocketaf/blob/248a2cb0dcffa51996c3ad7643577dce75d67454/lib/websocketaf.mli#L230
In Dream, I chose to treat chunks as the frames in my reader, i.e. if a frame is split into multiple chunks during reading, I just emit those chunks, and report
FINwith the last chunk of the last frame. However, because theon_eofcallback gets called after that last chunk, I have to cache each chunk until the reader knows whether the next callback turns out to beon_eofor not.I chose to have the reader report
FINwith the last chunk, rather than also with a separateon_eofcallback, for symmetry with WebSocket writing, because the WebSocket protocol requiresFINto be provided with the last frame. Providing it after the last frame would similarly require a WebSocket writer to cache each chunk until it knew whetherFINwas set by a nexteofcall or not.I think it would be better to remain consistent with the WebSocket protocol and writers, and have
schedule_readsomehow report the last chunk in theon_readcallback.I think it's possible to get a similar effect by tracking the total number of bytes read and comparing to the length from the frame header, but I am not sure how trustworthy that is.