Open veeg opened 6 years ago
i have the same question:
(proc 3215): (debug) nopoll_conn.c:3069 === START: conn-id=2 (errno=0, session: 3, conn->handshake_ok: 1, conn->pending_ssl_accept: 0) === (proc 3215): (debug) nopoll_conn.c:3275 Received 2 bytes for websocket header (proc 3215): (debug) nopoll.c:744 byte (header[0]) = 1 0 0 0 0 0 1 0 (proc 3215): (debug) nopoll.c:744 byte (header[1]) = 0 1 1 1 1 1 1 0 (proc 3215): (debug) nopoll_conn.c:3313 interim payload size received: 126 (proc 3215): (debug) nopoll_conn.c:3352 Received (2) bytes in header (size 4) for payload size indication, which finally is: 647 (proc 3215): (debug) nopoll_conn.c:3447 Detected incoming websocket frame: fin(1), op_code(2), is_masked(0), payload size(647), mask=0 (proc 3215): (debug) nopoll_conn.c:3503 Received fewer bytes than expected (bytes: 142 < payload size: 647)
I have a websocket client (through the browser implementation of WebSocket) that will upload small files in the range of 10-100kb. My server is using a nopoll listening socket with GLib event loop to receive complete messages through
nopoll_comm_get_msg()
on socket activity. When my client sends a message of some significant size, the TCP segments exchanged may be broken into anything between 2 and 12 packets. However, as exemplified by this wireshark TCP dump it is only sent as a single websocket fragment.TCP segments:
[4 Reassembled TCP Segments (32401 bytes): #62(8192), #63(8192), #65(8192), #66(7825)]
Hex dump of websocket fragment header:
82 fe 7e 89 56 41 bd 0f
Wireshark text interpretation of fragment header:
This is my nopoll/server log of received noPollMsg objects:
NOTE: The wireshark dump and log here is not the same occurrence. Only included the wireshark dump for sake of argument.
In this case, nopoll was able to read 28952 out of 32393 payload bytes from the socket in the first noPollMsg, and was able to read the remaining 3441 bytes in the next noPollMsg, however; the
is_final
flag is incorrectly set in the first noPollMsg while there are pending payload bytes left to complete the websocket message.This has been taken into account here: https://github.com/ASPLes/nopoll/blob/e80b74aa653b1395759bce7f256ce7e94645f39f/src/nopoll_conn.c#L3518 Hhowever, this was commented out in commit 4bc7339708bd7f64afcf2e773b5aed76bb5741fc, which is seemingly unrelated to the commit itself. After reverting the change and commenting in the clearing of this flag, I successfully received two noPollMsg objects for this fragment, where the first noPollMsg had is_final cleared.