1. Main features of Socket.D
First of all, Scoket.D is an efficient binary network communication protocol (the official statement is: a network based on events and semantic message flow application protocol), which can be used in many scenarios. Secondly, Scoket.D is mildly reactive (with callback style).
1. Three communication modes
- send just sends (don’t care after sending)
Send a request without sending a reply message for this request. It is suitable for monitoring buried points, log reporting, etc. In this scenario, no receipt is required, and it does not hurt to lose a few requests.
- sendAndRequest (send and request, ask for a "reply")
Send a request message, and the responder will send back a reply message after receiving it. Traditional HTTP is a typical sendAndRequest.
- sendAndSubscribe (send and subscribe, can receive N "replies")
Send a subscription message, and the responder will send back N reply messages after receiving it. Traditional MQ is typically sendAndSubscribe.
2. Two-way monitoring of two-way conversations
Server can listen to messages sent by Client; Client can also listen to messages sent by Server. The formed Session can even send messages to each other.
3. Others
- Binary protocol, compact and efficient
- There are discussions and events
- Multiplexing
- Flexible transport layer switching: TCP/UDP/WebSocket, etc.
- Supports advanced automatic grading features
4. Comparison with other protocols
It feels like the advantages of each protocol are purified. Simple yet powerful, very futuristic!
| Compare items | socket.d | http | websocket | rsocket | socket.io |
|---|---|---|---|---|---|
| Send message (Qos0) | have | none | have | have | have |
| Send and request (Qos1) | have | have | none | have | none |
| Send and subscribe | have | none | none | have | none |
| reply or response | have | have | none | have | none |
| Single connection two-way communication | have | none | Yes (inconvenience) | have | Yes (inconvenience) |
| Data sharding | have | / | none | have | have |
| Automatic reconnection after disconnection | have | / | none | have | have |
| meta information | have | have | none | have | none |
| There is an event (or path) | have | have | none | none | have |
| There is a flow (or message correlation) | have | none | none | have | none |
| Broker mode cluster | have | none | none | have | none |
| asynchronous | asynchronous | Synchronize | asynchronous | asynchronous | asynchronous |
| Interface experience | classic | classic | classic | Responsive (complex) | classic |
| basic transport protocol | tcp, udp, ws | tcp | http | tcp, udp, ws | ws |
2. Internal implementation of Socket.D
1. Frame design
socket.d transmits in frames. Large frames will also be automatically fragmented into small frames for transmission (automatic splitting and reassembly if more than 16MB, size configurable), and then automatically aggregated after reaching the receiving end.
- The logical structure of the frame
frame: {flag, message: {sid, event, entity: { metaString, data}}}
The data logical structure of the frame: there are flags and messages in the frame; stream identifiers, events, and entities in the messages; meta-information strings and data in the entities.
- Complete standard frame code
[len:int][flag:int][sid:str(<64)][\n][event:str(<512)][\n][metaString:str(<4k)][\n][data:byte(<16m)]
| Field | type | size | illustrate |
|---|---|---|---|
| only | int | 4 bytes | Frame length (including its own 4-byte placeholder) |
| flag | int | 4 bytes | Flags (equivalent to protocol instructions) |
| sid | String | Within 64 bytes | Stream ID.格式为： guid |
| event | String | Within 512 bytes | event.格式为：可见字符 string |
| metaString | String | Within 4Kb | Meta information string.格式为：通用的 uri queryString |
| data | byte[] | Within 16Mb | data.格式为： byte[] |
Note: When using udp transmission, the frame length cannot exceed 2k (I heard that it cannot actually exceed 1.4k)
- Simplified auxiliary frame code (Ping, Pong, Close), canceling the message part
[len:int][flag:int]
2. Data entity——Entity
Based on frames, developers generally come into contact with Entity, which is similar to an HTTP message and can be a Request or a Response. Consists of two parts:
- MetaString meta information string, similar to HTTP header. Format: string
- Data data, similar to HTTP body. Format: binary
3. How to play
Socket.D has many ways to play. Traditional RPC is not a problem. It is also suitable for IM. Developing MQ is also very simple (FolkMQ It was developed using it). Certain features can also be used for proxying or network penetration. In an IoT scenario, for example, Xiao Ming has a smart air conditioner in his home. Xiao Ming wants to control the air conditioner switch through a mobile phone APP outside. How to describe this control problem elegantly? The most refined solution is "Xiao Ming calls the API of the switch on the air conditioner".
In addition, the most classic way to play is Broker. Broker is similar to a "soft routing" solution, which can make it easier to publish and access services. To publish a service, you only need to connect to the Broker, and the caller can transparently forward it to the Broker through a reverse request, abandoning the traditional registration center, port management and other common service management methods.
4. About Socket.D Broker
Broker has many advantages. Publishing services does not require listening ports or sidecars. Service registration becomes simple without zk, etcd, etc. LoadBalance becomes simpler and more secure. It is difficult to attack without listening ports. There are also many disadvantages. There is an extra hop on the network, and there is a certain loss in performance. Broker is a centralized design, similar to our usual global Nginx, but the graceful start and stop of Broker is obviously more complicated and is limited by the bottleneck of the entire Broker cluster. etc. When God closes a door for you, He will definitely open a window for you.
3. Responsive programming, is it difficult?
Reactive programming is an old topic. It is already everywhere. Even SUM in Excel is essentially reactive thinking. Responsiveness is essentially a flow of data that responds to changes. The Socket.D protocol itself is called responsive and extends it to the network level.
However, the reactive interface is not very friendly to ordinary programmers. Socket.D is responsive, but uses a "classic callback interface".
4. Summary
Socket.D is a very interesting network protocol and should become popular in the future. Its problem-solving ideas and design are refreshing. If you are interested, you can go to its official website to learn more.