Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WebSocket Second Response Contains Invalid Data Causing SDK Error #1091

Open
Ilya-Vys opened this issue Feb 10, 2025 · 1 comment
Open

WebSocket Second Response Contains Invalid Data Causing SDK Error #1091

Ilya-Vys opened this issue Feb 10, 2025 · 1 comment

Comments

@Ilya-Vys
Copy link

Hi all!
I am experiencing an issue in our mobile application when establishing a WebSocket connection. I start a timer that sends a short command (b1000_0) at an interval of n seconds to request data. While the first response returns valid data, the second response does not, leading my SDK to throw an error during processing and subsequently close the connection.

This issue is not limited to the b1000_0 command; similar behavior is observed with each other requests as well—always, the first response is valid, and the second response is invalid.

My connection request and response headers:
Request Headers user-agent: [Dart/3.6 (dart:io)]connection: [Upgrade]cache-control: [no-cache]accept-encoding: [gzip]content-length: [0]sec-websocket-version: [13]host: [...]sec-websocket-extensions: [permessage-deflate; server_no_context_takeover; client_max_window_bits=9]sec-websocket-key: [....]sec-websocket-protocol: [zap-protocol-v1]upgrade: [websocket]

Response Headers connection: [upgrade]date: [Mon, 10 Feb 2025 11:22:39 GMT]sec-websocket-version: [13]sec-websocket-extensions: [permessage-deflate; server_no_context_takeover; client_max_window_bits=9]sec-websocket-protocol: [zap-protocol-v1]server: [nginx]upgrade: [websocket]sec-websocket-accept: [...]

Valid data taken(1 request):
["0xc1", "0x5a", "0x44", "0x8b", "0x4d", "0xa", "0x80", "0x20", "0x14", "0x6", "0xef", "0xf2", "0xd1", "0x52", "0x42", "0x2c", "0x10", "0xba", "0x8c", "0xd8", "0xcb", "0x40", "0xe8", "0x47", "0x52", "0xa1", "0x10", "0xef", "0xde", "0xab", "0x16", "0xed", "0x66", "0x6", "0xa6", "0x60", "0xb4", "0x8b", "0xdd", "0xc8", "0x61", "0x28", "0x3f", "0x42", "0x77", "0xaa", "0xed", "0x35", "0x4", "0x26", "0x17", "0xf6", "0xe8", "0x13", "0x27", "0xd9", "0x4a", "0xc9", "0x21", "0xae", "0xd1", "0xd0", "0x9e", "0x37", "0x4e", "0x52", "0xc0", "0x12", "0x99", "0x74", "0x5", "0x5e", "0x94", "0x0", "0xe5", "0xc3", "0xf8", "0xe9", "0xc5", "0x70", "0xb8", "0xd9", "0x9f", "0x7c", "0x35", "0xcf", "0x92", "0xe7", "0x4f", "0x50", "0xeb", "0xd"]
Invalid data taken(2 request)
["0xc1", "0x6", "0xaa", "0xa6", "0xb3", "0x7d", "0x0", "0x0"]

In this simple example, the second request returns significantly less data than expected – it should return roughly the same amount. When requesting heavier objects sized 300–400 bytes, the second request returns 5–10 bytes less. What could be the potential reasons for this behavior?

@fuzqing
Copy link
Contributor

fuzqing commented Feb 14, 2025

What did you do? If possible, provide a simple script for reproducing the error.

What version of Workerman are you using?

This might answer your question: #1052 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants