Cerl2 Series 5: SDL and my thoughts on network protocols

Network Protocol is the most critical role in network programming. This is just like the module interface that I care about most when programming on the client. The network protocol is an interactive interface between the client (B or C) and the server (s.

 

When I focus on network protocols, it is different from what many people care about. Many people ask me, do you like to use soap, rest, or define network protocols yourself? Do you like XML or JSON? In a sense, I don't care about this. For me, these are just the carriers of network protocols.

 

When talking about network protocols, we should realize that there are actually two meanings:

1. The carrier of the Protocol. That is, the specific Protocol encoding method used. Is soap, rest, or custom?
2. The logic of the Protocol.

In most cases, I pay more attention to the latter. How to express logic in the clearest way? My answer is: SDL.

 

SDL is a DSL (domain-specific language) used to describe server interfaces ). In the previous article, I introduced cerl SDL syntax and type system. And I said: the SDL language is the most important achievement in my opinion in the cerl library.

 

Why do we need a DSL? This involves my simple view of information representation: the more common the information representation means, the longer the information representation. For example:

 

Example 1: For formula A + B * C; if we use XML, it may be like this:

 

<Add>
<Var name = "A"/>
<Mul>
<Var name = "B"/>
<Var name = "C"/>
</MUL>
</Add>

 

Example 2: For functions: func (int32 A, string B)-> {OK, string Val} | {error, int32 reason}; if we use XML, how do I express it? (This is a long time. I skipped it here)

 

Therefore, it is natural to introduce DSL to solve the complexity problem of information representation in any professional field. I spent so much time describing this issue because I found that some people are so admired for XML or JSON that I forgot what I used for. xml/JSON.

 

We say that SDL is a DSL describing server interfaces, but this sentence has not been fully described.

 

Another key point in understanding SDL is to understand one thing: SDL is not a complete network protocol. As mentioned above, there are two layers of network protocols: Protocol carrier and Protocol logic. SDL only focuses on protocol logic.

 

Therefore, the same SDL has many compilers to generate different programming models and client and server framework code under different network protocols.

 

For example. We Use SDL to write a server:

 

Server hashserver
{
[ID = 1] Put (string key, string Val)-> OK;
[ID = 2] Get (string key)-> {OK, string Val} | false;
}

 

If we use the Venus model to implement the server, use the venusc compiler to compile and generate client call code and Server framework. If we use the Mars model to implement the server, compile it with marsc.

 

What if the Protocol needs to use soap instead? At this time, it is not compiled by a compiler such as soapc. Instead, it provides a compatible compiler such as venus2soap or mars2soap to compile it.

 

That is to say, in cerl2, our server programming models only include Venus and Mars. While soap is a network protocol, it is not a programming model. We can use the Venus model or the Mars model.

 

Conclusion: Venus and Mars are programming models, not protocols (Note: however, venusc or marsc does generate a custom network protocol, but it is not necessary. If we use venus2soap, the programming model uses venus and the network protocol uses soap ).