Support Message Fragmentation
Nobody has claimed this yet.
- Dominant language
- Lua
- Stars
- 419
- Forks
- 117
- PR merge metrics
- No merged PRs in 30d
Description
I thought of spinning my observation from here https://github.com/lipp/lua-websockets/issues/94#issuecomment-222781768 into separate issue, here it goes:
It seems that receive (not only in sync but otherwise too, see https://github.com/lipp/lua-websockets/search?utf8=%E2%9C%93&q=first_opcode ) concatenates bunch of frames into a single string and returns the 1st opcode only! Meaning that if the 1st opcode was PONG, everything will get labeled so, regardless it is BINARY/TEXT. Or if the 1st opcode is BINARY and PONG is one of the next frames, it will disappear.
When i think of it - a mix of BINARY / TEXT / etc all gets "mushed" together and that should not be the case. Because e.g. TEXT is UTF8 and should be handled differently.
Seems to me a proper handling should return only 1 frame and its corresponding 1 opcode, keeping the rest for the next call - perhaps akin to how i "save" frames for later consumption in #80
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by tracing receive handling using the `first_opcode` search results and compare it with the frame-saving approach discussed in issue #80. Reproduce mixed BINARY, TEXT, and PONG frames, then verify that each call returns one frame with its matching opcode while later frames remain available.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- lua
- Domain
- networking
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 42/100