docs: add more docs

Author: bytemain

packages/connection/docs/sumi-rpc/connection.md

@@ -0,0 +1,35 @@
+# Connection
+
+OpenSumi RPC Connection is highly inspired by the [JSON-RPC](https://www.jsonrpc.org/specification) specification, but we use FURY instead of JSON. The protocol is defined in the [packet.md](./packet.md). It is transport agnostic in that the concepts can be used within the same process, over sockets, over http, or in many various message passing environments.
+
+## Why not JSON?
+
+JSON is a great format for many things, but it is not the best format for high performance RPC. The main reason is that JSON is a text-based format, and it is not very efficient to parse and serialize. It is also not very efficient to send over the wire. FURY is a binary format that is much more efficient to parse and serialize, and it is also much more efficient to send over the wire.
+
+## Conventions
+
+The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119](http://www.ietf.org/rfc/rfc2119.txt).
+
+We use `@furyjs/fury` as our protocol format, `@furyjs/fury` is a high performance protocol buffers implementation, it is much faster than `protobuf.js` and `JSON`.
+
+And also we use the `BinaryReader` and `BinaryWriter` from `@furyjs/fury` to operate the binary data.
+
+`@furyjs/fury` support many types, such as Object, Array, String, Number, Boolean, Null, Undefined, Date, Buffer, Map, Set, and so on.
+
+All member names exchanged between the Client and the Server that are considered for matching of any kind should be considered to be case-sensitive. The terms function, method, and procedure can be assumed to be interchangeable.
+
+The Client is defined as the origin of Request packets and the handler of Response packets. The Server is defined as the origin of Response packets and the handler of Request packets.
+
+## Packets
+
+The Request/Response Packet is binary format, you can see the [packet.md](./packet.md) for more details.
+
+### Request
+
+#### Notification
+
+#### Cancel
+
+### Response
+
+#### Error

packages/connection/docs/ws-channel.md

@@ -0,0 +1,7 @@
+# WSChannel
+
+## Description
+
+`WSChannel` 一开始是为了支持在浏览器环境下同时支持创建两个 RPCService 实例而出现的。我们在浏览器的 Browser 层需要和 Main 和 Ext 两个环境进行通信，建立两个 WebSocket 连接显然是不合适的。因此我们需要一个能够支持多路复用的 WebSocket 连接，然后 `WSChannel` 和 `WSChannelServer` 就应运而生。
+
+其实这种多路复用是非常有用的，在 Node.js 里我们也需要它，因为我们也会需要在一个 `net.Socket` 连接中同时传输多种信息。我遇到的情况就是需要同时支持 `@vscode/jsonrpc` 和 sumi-rpc，所以我把 Node.js 的通信连接各种东西也改成了 `WSChannel`。