WebSocket client API – writable bytes changes unexpectedly

[phoddie]

This issue was reported to me by an anonymous developer who is experimenting with the Moddable SDK implementation of the proposed WebSocket Client.

WebSocket Client responds to ping messages. The response puts bytes into the TCP output buffer, reducing the number of bytes that can be written. Consider this sequence:

• Connection established
• onWritable is invoked with 1500 bytes writable
• The onWritable script stores the 1500 and doesn't write anything immediately
• A ping is received and responded to (with a pong)
• The number of bytes that can be written is now temporarily reduced by the size of the pong
• Before the TCP buffer clears, the script calls write with a message that uses all available bytes (1500). This write fails because the client thinks more bytes can be written than are actually available.

The solution that comes to mind immediately is that the WebSocket client replies to a ping, it should also invoke onWritable with the updated value.

N.B. We should check MQTT Client for similar issues.

[phoddie]

The solution implemented for the Moddable SDK WebSocket client is to invoke onWritable immediate after sending an automatic response (pong and close). That introduces a small change in the behavior observed by onWritable: previously it was only called when more space becomes available to write, but now it can also reduce the amount of space available to write. The current draft spec text for onWritable is:

A function to invoke when more data may be written to the connection.

This needs to change to eliminate "more", so something like this:

A function to invoke when there is a change in amount of data that may be written to the connection.

The MQTT Client has the same behavior and spec text, and so also needs a similar update.