Javascript implementation of mesh schema

[LivInTheLookingGlass]

I'm testing this against the python version.

Currently the implementation works as a passive receiver. I am currently working in ES6, with the intent to later translate into ES5 for browser compatibility. There are two open bugs:

• It currently connects to itself
• It cannot relay messages
• It sometimes cannot properly send messages
• It does not comply with the renegotiation schema
• It cannot use the request/response mechanism
• It cannot clean old connections
• It is not an event emitter (but you can register handlers, so...)

[LivInTheLookingGlass]

Okay, looks like opportunistic compression is failing. Or at least providing results that Python can't read. Time to investigate.

[LivInTheLookingGlass]

This isn't a failure of opportunistic compression. It's a failure of encoding somewhere down the line. When Javascript sends its message over a socket, it comes out as '\x00\x00\x00\xfd\x00\x00\x00\x01\x00\x00\x00B\x00\x00\x00B\x00\x00\x00\x06\x00\x00\x00\x01\x00\x00\x00[\x025t1SaHt2F9JP3Saqrh1vxTQcCXmQ5iyCZgWK6w4HPmFyp1zgoNsN9SQEgJMv4s28bxAJ8sKAcUgPEogYiu9ztMLggZPFoJrqAYLKnNSmXUc9YQgoDHqfJPGxJsU3nDXYrUB83FGoRh\x07[[["localhost",3333],"2tosXNUvh36yKwD8EgUspGtkDp2GNTAYPNbEhRtQzxGxLPkhqdiVq8PE15omQjBzWi"'.

Python recognizes this as invalid (which it is), so it disconnects. Javascript also recognizes this as invalid. So the question becomes, when is the invalid information getting in? Is it on message construction? Is it on message transmission?

[LivInTheLookingGlass]

It's not just a matter of a packet size descriptor being wrong. Changing the message to get correct packet sizes doesn't seem to fix the problem. Of course, I could be modifying it incorrectly, which would also yield the checksum failure I'm seeing.

[LivInTheLookingGlass]

The string it was supposed to generate was:

'\x00\x00\x00\xff\x00\x00\x00\x01\x00\x00\x00B\x00\x00\x00B\x00\x00\x00\x06\x00\x00\x00\x01\x00\x00\x00[\x025t1SaHt2F9JP3Saqrh1vxTQcCXmQ5iyCZgWK6w4HPmFyp1zgoNsN9SQEgJMv4s28bxAJ8sKAcUgPEogYiu9ztMLggZPFoJrqAYLKnNSmXUc9YQgoDHqfJPGxJsU3nDXYrUB83FGoRh\x07[[["localhost",3333],"2tosXNUvh36yKwD8EgUspGtkDp2GNTAYPNbEhRtQzxGxLPkhqdiVq8PE15omQjBzWi"]]'

There were two changes made to the string.

First, two characters were left off the end. That's the "]]".

Second, the total length field was mutated by this.

However, the checksum was not changed. This is weird, since it's based on contents that were changed. It would appear that this error is just isolated to the packet sizing methods. For instance, a message with a length of 255 is self-reporting as being 239 characters. Or 253 if you put it through a Buffer first. It's very odd, and needs serious investigation.

[LivInTheLookingGlass]

This is fixed in 102f44c

[LivInTheLookingGlass]

Oh, and I need to remove all these debug prints at some point. This is ridiculous.

[LivInTheLookingGlass]

Kay. Debug prints removed except where it's obvious to have them. Connection cleaning added. So there's a basically-full implementation in less than 72 hours (given an existent parser). Now I just need to figure out how to get testing set up, and see if the compression support works properly.

[LivInTheLookingGlass]

Enabled again. Seems to work.