在《CERL2 系列5：SDL与我对网络协议的思考》一文中，尽管我对 SDL 的来龙去脉做了介绍，但是我发现还是遗漏了非常重要的内容。朋友们可能会问，SDL看起来不就是一个普通的IDL（接口描述语言）吗，为什么不直接沿用一个现成的标准呢？

 

很多时候，看似相似的东西却会是貌似神不是。正是因为我觉得IDL并不符合我对网络接口协议的观点，所以才有了 SDL。

 

首先，多数 IDL 都是面向对象的。但是我认为网络协议应该是面向数据流的。为什么在网络协议中，面向对象是坏的呢？

 

原因很简单。面向对象的网络协议必然增加实现的复杂性。由于我们可以在网络流中传递对象，那么自然而然，对象就需要在服务端存在存根（Stub），在客户端存在代理（Proxy）。而特别让人讨厌的，是对象生命周期的管理。这些都给服务端、客户端带来实现难度。如果说加大服务端的复杂度影响不算太大的话，客户端的难度增加，无疑使得协议的跨语言调用变得更加困难。

 

面向数据流的网络协议很直观，消除了一切面向对象带来的负累。我们对在网络中传递的数据有着非常清晰的概念。在简单对协议细节进行了解后，你可以在没有任何基础的情形下，很快做出一个新的语言的客户端调用代码。

 

简单是美。这是面向数据流的网络协议的魅力所在。

 

体现 SDL 简单的另一个层面，是 SDL 的接口描述方式。对于这样一个声明：

 

   [id=2] get(String key) -> {ok, String val} | false;

 

你可以看到， -> 符号之前的是 request 包，-> 之后的是 response 包。这非常直观。你可以对比下这样的一个声明：

 

    [id=2] bool get([in] String key, [out] String* val);

 

两者的阅读体验不是在同一个档次上的。

 

特别是，在 response 的分支情况很多的时候，第二种描述方式就会惨不忍睹。

 

所以，从各种角度讲，SDL 是我认为描述网络协议的接口最佳选择。