From d499a6e7f58d967e3a84f879e05c82ef2f55458f Mon Sep 17 00:00:00 2001 From: chrislonng Date: Tue, 8 Aug 2017 18:52:21 +0800 Subject: [PATCH] docs: communication protocol --- README.md | 11 +++++------ docs/communication_protocol.md | 26 +++++++++++++------------- 2 files changed, 18 insertions(+), 19 deletions(-) diff --git a/README.md b/README.md index 5a3dab3b..edc6d6c0 100644 --- a/README.md +++ b/README.md @@ -25,6 +25,11 @@ go get -u github.com/gorilla/websocket - [Communication protocol](./docs/communication_protocol.md) - [Design patterns](./docs/design_patterns.md) +## Demo + +- [Implement a chat room in 100 lines with nano and WebSocket](./examples/demo/chat) +- [Tadpole demo](./examples/demo/tadpole) + ## Benchmark ```shell @@ -37,12 +42,6 @@ cd $GOPATH/src/github.com/lonnng/nano/benchmark/io go test -v -tags "benchmark" ``` -## Demo - -- [Implement a chat room in 100 lines with nano and WebSocket](./examples/demo/chat) -- [Tadpole demo](./examples/demo/tadpole) - - ## License [MIT License](./LICENSE) diff --git a/docs/communication_protocol.md b/docs/communication_protocol.md index a8110f4d..28096369 100644 --- a/docs/communication_protocol.md +++ b/docs/communication_protocol.md @@ -10,7 +10,7 @@ can be replaced independently since neither of them relies on each other directl The layers of nano protocol is shown as below :
-![Nano Protocol] (images/data-trans.png) +![Nano Protocol](https://raw.githubusercontent.com/lonnng/nano/master/docs/images/data-trans.png)
## Nano Package @@ -27,7 +27,7 @@ length of the package while body contains the binary payload which is encoded/de message layer. The format is shown as follows:
-![nano package](images/packet-format.png) +![nano package](https://raw.githubusercontent.com/lonnng/nano/master/docs/images/packet-format.png)
* type - package type, 1 byte @@ -64,9 +64,9 @@ A handshake request is shown as follows: ``` * sys.version - client version. Each version of client SDK should be assigned a constant -version, and it should be uploaded to server during the handshake phase. + version, and it should be uploaded to server during the handshake phase. * sys.type - client type, such as C, android, iOS. Server can check whether it is compatible -between server and client using sys.version and sys.type. + between server and client using sys.version and sys.type. A handshake response is shown as follows: @@ -91,7 +91,7 @@ A handshake response is shown as follows: The process flow of handshake is shown as follows:
-![handshake](images/handshake.png) +![handshake](https://raw.githubusercontent.com/lonnng/nano/master/docs/images/handshake.png)
After the underlying connection is established, client sends handshake request to the server @@ -105,7 +105,7 @@ A heartbeat package does not carry any data, so its length is 0 and its body is The process flow of heartbeat is shown as follows:
-![heartbeat](images/heartbeat.png) +![heartbeat](https://raw.githubusercontent.com/lonnng/nano/master/docs/images/heartbeat.png)
After handshaking phase, client will initiate the first heartbeat and then when server and @@ -137,24 +137,24 @@ Message header is composed of three parts: flag, message id (a.k.a requestId), r shown below:
-![Message Head] (images/message-header.png) +![Message Head](https://raw.githubusercontent.com/lonnng/nano/master/docs/images/message-header.png)
As can be seen from the figure, nano message header is variant, depending on the particular message type and content: * flag is required and occupies one byte, which determines type of the message and format of -the message content; + the message content; * message id and the route is optional. Message id is encoded using [base 128 varints](https://developers.google.com/protocol-buffers/docs/encoding#varints), -and the length of message id is between the 0~5 bytes according to its value. The length of -route is between 0~255 bytes according to type and content of the message. + and the length of message id is between the 0~5 bytes according to its value. The length of + route is between 0~255 bytes according to type and content of the message. ### Flag Field Flag occupies first byte of message header, its content is shown as follows:
-![flag](images/message-flag.png) +![flag](https://raw.githubusercontent.com/lonnng/nano/master/docs/images/message-flag.png)
Now we only use 4 bits and others are reserved, 3 bits for message type, the rest 1 bit for @@ -170,7 +170,7 @@ by 2-4 bit of flag field. The relationship between message types and message hea as follows:
-![Message Head Content](images/message-type.png) +![Message Head Content](https://raw.githubusercontent.com/lonnng/nano/master/docs/images/message-type.png)
**-** The figure above indicates that the bit does not affect the type of message. @@ -182,7 +182,7 @@ where 1 means it's a compressed route and 0 for un-compressed. Route field encod on this bit, the format is shown as follows:
-![Message Type](images/route-compre.png) +![Message Type](https://raw.githubusercontent.com/lonnng/nano/master/docs/images/route-compre.png)
As seen from the figure above: