handle incoming end without feeding messages back into itself #41

Closed
wants to merge 2 commits into
from

3 participants

@dominictarr

this was causing quite a crazy problem over here:

dominictarr/scuttlebutt#27 (comment)

The streams where literally getting crossed. Sometimes a very large packet would come in
and it would be cut in half with a packet from from it self.

since tr.write = function (buf) { s.write(buf) }; and s.pipe(tr) it was actually feeding it's own output back into it's input.

So, if an incoming message is so large that it's split, and meanwhile an update occurs,
then that will update will write a message into it's input, concatenating it with the half a message that is already there.

This caused stream-serializer to throw, and crash.

I've also added an error listener to the scuttlebutt stream.
This will safely destroy the stream and log a message to stderr.
(this should pretty much never happen, of course)

Also, I've patched a race condition in scuttlebutt.
Now, the update listener is not registered until the history is queued,
So messages cannot be out of order.

the seaport tests pass, with the new scuttlebutt version.

Also:

image

@substack
Owner

Published in 1.5.3.

@substack substack closed this Aug 26, 2013
@dominictarr dominictarr referenced this pull request in dominictarr/scuttlebutt Aug 26, 2013
Closed

Very large messages getting clipped? #27

@juliangruber

:D one of my favorite pull request!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment