I am currently failing #PV1 because of 4 trailing bytes being present in the decode buffer. I cannot reproduce that locally, I double check the size of the bytes, dump the hex, I even checked with strace to see if I was missing anything. Any chance the test runner is doing something weird?
My current codebase:
As you can see from the debug logs I added what is being sent does not include those trailing bytes. And everything I sent seems to be decoded correctly?:
@andy1li that is exactly the problem I am hitting, yes! But I cannot reproduce those 4 additional bytes locally, can you? Any chance the tester may be misbehaving? If you look at my debugging messages that appear on the tester execution, the 4 bytes also do not show up there:
The first four bytes are: 00 00 00 17, which corresponds to 23 in hexadecimal. Thus, the tester expects 23 ADDITIONAL bytes to be sent after them, and not 23 - 4 = 19 bytes that your implementation is doing.
You need to exclude the 4 bytes of message length bytes from the message length. The simplest way of doing same would be:
The error message you see extra bytes is due to the tester allocating the buffer size of 23, then reading only 19 bytes and using 4 bytes (which were 0 by default) during the decoding process.
Unrelated: @andy1li Can we update the tester to actually read exactly the bytes that have been sent by the client, and throw an error if the same doesn’t happen? It would help to prevent flagging of error at the wrong place (decoding instead of message length).
A fundamental truth of sockets: messages must either be fixed length (yuck), or be delimited (shrug), or indicate how long they are (much better), or end by shutting down the connection .
Hmm makes sense. I was under the impression but using methods like conn.ReadFull should take care of the “exact reading” problem I was referring to, but turns out even they can’t guarantee 100% correctness, cause it’s the limitation of the socket spec itself! TIL.
Oohhh ok, that makes sense. I counted those bytes by hand several times @andy1li if I could make a suggestion, it would be great if message size was validated on a previous step, as there is already too much going on in this step and it’s not obvious at first (or at least it wasn’t for me) that the message size is not included in its calculation. Thank you both!