Implement WebSocketProtocol using WebSocketFrameReader/Writer

[mattnischan]

Now that there is the ability to read and write raw WebSocket frames, the actual protocol can be implemented. There are probably some API questions worth getting opinions on.

The corefx WebSocket API leans very heavily in a Stream paradigm. Is that the direction we want to go, or would a more message based API be better? The WebSocket protocol is actually not hugely friendly here, living in no-man's-land between a streaming protocol and a message based protocol. Frames can be exabytes long, and messages can have an infinite number of frames, the number of which isn't in any header information.

A Pipe type of API is actually almost perfect, except with Pipe there isn't a way to indicate end-of-message out of ReadAsync.

[davidfowl]

A Pipe type of API is actually almost perfect, except with Pipe there isn't a way to indicate end-of-message out of ReadAsync.

This has come up a number of times but as you said, there's no way to preserve the incoming frames for what a "message" is with a PipeReader, it represents streaming data.

Before designing a higher level API, it would be interesting to see what it looks like to use the raw websocket APIs with the ProtocolReader and ProtocolWriter in an ASP.NET Core application (I'll try that out) and find the warts.

[mattnischan]

So, I've actually been playing around with some implementations the past week and I think I'm on to a somewhat unique solution which involves putting another message reader over the WebSocketFrameReader.

Effectively the high level API then becomes WebSocketMessage, containing the message type and a MessagePipeReader (which can be reset and recycled when the next message comes in). The only wrinkle I'm running into is that control frames (ping, pong, close) can arrive at any time, even in between other message frames, but I think I have an idea for that as well.

My plan was to get this cleaned up and put in a WIP PR in the next day or two.