Handling < 4 byte first data chunks #50
Conversation
…first chunk previously causing an out of range exception
|
Thanks! Any chance we could get a test on that scenario too? |
…onse length not including the space to it is written to
|
Sure, I can look into one. In the meantime, I found that the amount of buffered response being waited for was off by 4 bytes. This resulted in a very rare problem when a response was split into packets such that the last packet was less than 4 bytes of payload data. By the time it arrived, the consumer would have already fired its callback and would think this was a new response. I think this was the original "cause" of the bug where there would be less than 4 bytes to read (as it was reading a 1-3 byte tail packet from the previous response). |
|
Added is a test case that fails on the current master (due to reading past the end of the buffer) and hangs on my first fix (due to not reading enough of the buffer). The current PR survives this test. Sorry for the "ugly" method of fragmenting the packets. All attempts at being nicer failed and ultimately I had to use setTimeout to give it enough time to send the packets without buffering them at the user or kernel level |
Handling < 4 byte first data chunks
|
Thanks... this makes me wonder if this also fixes this one: #44 . |
|
The test is great too BTW... I don't have a better way to fake that scenario than setTimeout either. Nice work! |
|
just published in 0.7.3 |
when the data handler is called for the first time on a new message and less than 4 bytes are passed, this segment of code would throw a RangeError('Trying to access beyond buffer length');
The change requires the code to wait for at least 4 bytes and potentially re-assemble the buffers to read that initial message size from the buffer. If the buffer is complete, it will not re-concat.