采访SimplSockets的创建者David Haney

我们就当前环境下TCP编程相关的问题采访了SimplSockets for .NET的创建者David Haney。

InfoQ：现在大多数人好像更乐于使用HTTP协议而不是像TCP这样的更底层的协议。那么你认为TCP和UDP依然重要的原因是什么？

HTTP是一个非常优秀的通信协议，可以用于许多目的和应用程序。它能够为你处理消息框架、错误码以及底层网络通信的其他方面，让通信变得非常简单。但是，这种易用性同时也伴随着由HTTP协议规范（建立在TCP协议之上）所引入的大量开销。虽然大部分应用程序能够从HTTP的简单性上受益匪浅，但是有一些应用程序则将网络性能视为成功的关键。这些应用程序的目标是将所有的空闲周期压榨出自己的代码从而实现吞吐量的最大化，而HTTP协议的开销和与其相关的头对于他们而言毫无意义。这种应用程序的示例是搜索引擎、分布式缓存解决方案以及视频流服务。对于这种类型的应用程序，HTTP根本不能匹配TCP或者UDP的性能。尽管实现起来更加复杂，但是TCP和UDP极大地提高了吞吐量，尽可能地实现了应用程序的高性能。

InfoQ： SimplSockets提供的哪些内容胜过了.NET内置的socket类库？

SimplSockets的目标并不是彻底改造已经运行良好的轮子，也就是.NET sockets；相反的，它是构建在.NET sockets之上的。在sockets之上实现定制通信协议的时候，有很多样板（boilerplate）或者“经典的”问题必须要处理，但是它们并不容易解决。例如，你并不能控制一个TCP socket如何分发你的消息。它可能会选择在一个包里面分发，也可能是10个包，甚至有可能是50个包，你必须做一些手工劳动将这些包的信息重新组合成原始消息。除此之外，TCP并不会告诉你还有多少字节的消息需要等待接收，所以你必须设计一个定制的协议头，通过它告诉接收器在消息完成之前还有多少字节的信息需要接收…...然后如果你接收到了一部分消息之后与发送者断开了连接，那么将会发生什么？你不能一直等待直到接收到所有的消息，所以你必须创建超时或者故障系统。因此，你在创建定制协议的这条路上走的越远，就会发现越多的问题需要处理，这个水会越来越深。

既然使用TCP sockets的其他所有人都需要解决这些问题，那么为什么还要自己去解决呢？这正是我对开源类库用途的感觉。因此，我构建了SimplSockets填充这个空白，同时解决了这些典型的TCP sockets问题，所有人都能够使用或者重用它。对于使用的定制协议，每个消息（不是每个包）伴随着8个字节的开销，但是我认为相对于它所带来的好处这是一个非常好的折衷。一个主要的好处是客户端多路技术：一个到服务器的开放连接可以被多个线程使用，完全是线程安全的。这样有助于避免端口枯竭以及设置/销毁连接的开销。服务器端实现完全是异步的，同时利用了完成线程和专有对象池/再利用，让你的应用程序能够保持难以置信的性能。

SimplSockets的目标是让.NET sockets更好、更加易用，并不是为了与众不同或者专用。

InfoQ：SimplSockets有没有提供async/await或者IObservable支持?

SimplSockets没有提供async/await或者IObservable支持，这是由设计决定的。我想让没有使用.NET 4.5的人也能够使用SimplSockets，因为它实际上并没有依赖于任何.NET 4.5引入的功能。将.NET 4.0作为目标版本可以让更多的人使用它，但是将来我可能会针对.NET 4.5引入一个支持async/await的版本。

InfoQ：对于所有的开源项目而言许可都是非常重要的。为什么你会为SimplSockets选择GPL 3许可？

作为一个人类同时也是一位开发人员，我相信在学习和发展过程中分享知识是非常重要的。话虽如此，但是我同时也认为如果你的工作能够让其他人受益那么就应该获得报酬。结果便是我选择了GPL v3平衡自己的人生观：其他的开源或者免费项目可以免费使用它，但是另外一些打算从中受益的人必须依照商业许可付费。

InfoQ：你计划在将来版本的SimplSockets中实现哪些功能？

下一个版本将会包含一个更加强健的通信超时系统，支持可配置的超时间隔。除此之外，我希望发布一个能够在.NET Micro Framework上运行的SimplSockets版本，让.NET 驱动的底层嵌入式系统也能够利用它。除了路线图之外，我还计划处理用户对该类库的所有建议，同时愿意讨论潜在的改进；我并不认为一时半会就能找到所有的答案或者想的很全面。

查看英文原文：Interview with David Haney, Creator of SimplSockets