EagleAglow
commented
2 years ago Greetings - It's been a while since I wrote this, but I think I had in the back of my mind that in actual use, the code would just be modified to make the receive buffer large enough to handle anything the server sends. I've seen other websocket implementation with much larger buffers (64kB). Unfortunately, that still fails if the incoming message is longer. Associated question would be to find out the maximum length (if there is one) for the incoming JSON message.
I'm not actually using this repository for anything. It was a wobbly stepping stone to trying to write an asynchronous implementation (also wobbly).
You can make a pull request, or I can just transfer ownership of this repository over to you.
From: Kenneth J Davis Sent: Wednesday, February 16, 2022 6:42 PM To: EagleAglow/vba-websocket-class @.> Cc: Subscribed @.> Subject: [EagleAglow/vba-websocket-class] Fragmented receive issues for UTF8 messages (Issue #3)
In GetMessageUTF8, if the receive returns a fragmented message, it is not handled well. The next iteration of the loop will overwrite the whole buffer replacing the initial received bytes. My initial fix was to increase the buffer size and track where in the buffer (which it looks like at some point that is/was the intent) but it was lost. This however has issues as the buffer size can't be known in advance usually, so throws error with buffer to small on replies larger than the message (which Chrome/Edge can return JSON messages over 4KB). So instead I convert the portion received to a string and concatenate with previously received portions (already converted). This however can cause issues if the message is fragmented in the middle of a utf8 sequence. I look for the start of the last lead byte and see how many bytes are actually sent and keep that in the buffer starting the next receive just past them. (I'm still testing my implementation of this).
Would you be interested in a pull request that reworks GetMessageUTF8 so it better handles fragmented messages? You can see current my implementation here: https://github.com/PerditionC/VBAChromeDevProtocol/blob/b2ebd19b606b450fea8c3996ca82ca01e5ac3afd/src/clsWebSocket.cls#L570
Thanks.
— Reply to this email directly, view it on GitHub https://github.com/EagleAglow/vba-websocket-class/issues/3 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AQJ6I7RMVMOVBYPWWJLUOUTU3RN7XANCNFSM5OTMG7KA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub . You are receiving this because you are subscribed to this thread.Message ID: @.***>
https://github.com/EagleAglow/vba-websocket-class/blob/e3874f995e8d4b56c767e502c73dcfc3fabe6147/CWebSocket.cls#L489
In GetMessageUTF8, if the receive returns a fragmented message, it is not handled well. The next iteration of the loop will overwrite the whole buffer replacing the initial received bytes. My initial fix was to increase the buffer size and track where in the buffer (which it looks like at some point that is/was the intent) but it was lost. This however has issues as the buffer size can't be known in advance usually, so throws error with buffer to small on replies larger than the message (which Chrome/Edge can return JSON messages over 4KB). So instead I convert the portion received to a string and concatenate with previously received portions (already converted). This however can cause issues if the message is fragmented in the middle of a utf8 sequence. I look for the start of the last lead byte and see how many bytes are actually sent and keep that in the buffer starting the next receive just past them. (I'm still testing my implementation of this).
Would you be interested in a pull request that reworks GetMessageUTF8 so it better handles fragmented messages? You can see current my implementation here: https://github.com/PerditionC/VBAChromeDevProtocol/blob/b2ebd19b606b450fea8c3996ca82ca01e5ac3afd/src/clsWebSocket.cls#L570
Thanks.