Browser WebSocket Improvements

[lewing]

The current Browser ClientWebSocket implementation is using managed side buffering of partial writes, we should review wether we can push the writes to the browser and chain all the data there for the send call.

[ghost]

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

---

Issue meta data

Issue content:
	The current Browser ClientWebSocket implementation is using managed side buffering of partial writes, we should review the wether we can push the writes to to the browser and chain a the data there for the send call. </td>
Issue author:		lewing
Assignees:	-
Labels:	`area-System.Net`, `untriaged` </td>
Milestone:	-

[lewing]

cc @kjpou1 @kg

[kg]

We should just push it directly to the browser, I don't see any reason to do unnecessary work on the managed side unless it's addressing a bottleneck we found in a profiler.

[lewing]

No, the issue is just the api mismatch and we can track the write buffers on the browser side rather than in managed for the fragmented send.

[lewing]

Yeah, looking closer at the spec it appears we should: (edited - corrected some errors in the previous review)

• Get tests in place Browser WebSockets tests #44666
• Move all buffering to unmanaged, either as a chained blob or an array of write buffers.
• Validate when the send Task should complete (should it be after we've posted it or after the writeBuffer in the browser is empty, should it vary based on endOfMessage?)
• Review the expectations for the other states
• Review exception types
• Implement IWebProxy support

[lewing]

cc @kjpou1

[kjpou1]

Looking at it

[kjpou1]

So far looking at sample streams of chained blob and an array of write buffers.

Have not found a way to control the websocket text or string send type when using the above. It is always sent as binary.

WebSocketMessageType

Type	Value	Desc
Binary	1	The message is in binary format.
Close	2	A receive has completed because a close message was received.
Text	0	The message is clear text.

What controls this with fetch is the type of buffer that is passed.

Type	Data structure sent with fetch
Binary	Uint8Array
Text	string

This also controls how we receive data from a websocket using the same criteria. If the fetch body is text then we signify text and a blob or array buffer sent back is read and transferred back to the client as binary.

[lewing]

I added that distinction to #44666 lets start by getting some tests in place so that we can validate any changes.

[lewing]

cc @pavelsavara

[pavelsavara]

WebSocketStream would be nice if it was ready, but it is not.

[pavelsavara]

Thinking about design for send buffers:

when the endOfMessage == false

• We have to make copy anyway, as the C# owner of the buffer could rewrite it with new data.
• This copy needs to be done before we return the promise/Task.
• This promise would not be blocking on network, instead we would queue the buffer copy on the JS side.
• The queue would be stored new __pending_send_buffers__ property of the WS instance.

when the endOfMessage == true and there are queued partial messages.

• we need to concatenate all buffers in the __pending_send_buffers__ queue and then WebSocket.send it
• This call should also block the promise until WebSocket.bufferedAmount === 0, probably by polling from setTimeout 50ms

when the endOfMessage == true and there are NO queued partial messages.

• because WebSocket.send does copy of the buffer, we don't have to . We could directly pass Module.HEAPU8.subarray() as seen in our typedarray_copy_from.
• This call should also block the promise until WebSocket.bufferedAmount === 0, probably by polling from setTimeout 50ms