Document

.NET 的WebSocket开发包详细比较(2)

AlchemyWebSocket

http://alchemywebsockets.net/

当我想到websocket库时，这个让人不可思议。没错这是真的。它可以排在Fleck后面，它非常容易使用，容易安装（Nuget包可用），文档中含有很好的例子。

它包含服务端和客户端两部分，同时也具有可伸缩性

  1. static void Main(string[] args)  
  2. {  
  3.     // 创建一个新的server - 接受端口和ip范围,  
  4.     // 设置方法  
  5.  
  6.     var aServer = new WebSocketServer(81, IPAddress.Any)  
  7.     {  
  8.         OnReceive = OnReceive,  
  9.         OnSend = OnSend,  
  10.         OnConnect = OnConnect,  
  11.         OnConnected = OnConnected,  
  12.         OnDisconnect = OnDisconnect,  
  13.         TimeOut = new TimeSpan(0, 5, 0)  
  14.     };  
  15.  
  16.     aServer.Start();  
  17.     string consoleReadLine;  
  18.     do 
  19.     {  
  20.         consoleReadLine = Console.ReadLine();  
  21.         sockets.ForEach(s => s.Send(consoleReadLine));  
  22.     } while (consoleReadLine != "exit");  
  23. }  

但是它有一些别扭，我不能避开。例如那里没有简单的事件方法"OnReceive"，仅仅只有string，事实上消息在客户端被发送了。你必须你自己完成。是的，你必须调用，而且只能调用 .ToString()来得到真实的消息，但使用库的目的是为了不要强迫自己实现通信协议。

  1. private static void OnReceive(UserContext context)  
  2. {  
  3.     Console.WriteLine("Client " + context.ClientAddress.ToString() + " sended: " + context.DataFrame.ToString());  
  4. } 

WebSocket服务器初始化方法首先接收端口然后是IP设置。我一直认为，地址的表达应该是先IP然后是端口，而且只有当有必要指明端口的时候。还有超时设置：为什么必须有超时呢？我可以理解这有时可能是有用的，但它作为一个特性不应作为主要设置之一。当然，这只是一些细节问题。

对我来说这迫使你一开始就得通过这个库用另一层代码把它抽象出来。

总之你可以试试，和Fleck比较一下性能，然后决定哪个更适合你的简单项目。

优势：

  • 简单

  • 无依赖性

  • 文档完备

缺点：

  • 有点笨拙，比Fleck结构更复杂

  • 没有 fallback

XSockets

http://xsockets.net/

这个库看上去很有前途。我尝试过它，并且还花了很多时间，用它工作超过其它的库（甚至用来执行测试工作等等）。但是很不幸我没有运气，任何我考虑到的错误在这个库中都是错误的，与代码不一致的糟糕文档。难道是因为代码或者文档过期了？它不容易安装和运行，事实上这个库的使用样例我很难组建和运行。Xsocket更多向我们展示了MVC框架的样子。我尝试把它运行在ASP.NET项目里面，MVC和WinService，遗憾的是没有一个能够工作。

我真的很想用这个库，但最后我放弃了以便支持更好的库（阅读其他）。认真地说为什么使用这个库是困难的，甚至一个简单的项目。你可以预测更多的问题当把它使用在项目里，我强烈建议避开这个项目。

  1. public static class XSocketsBootstrap  
  2. {  
  3.     private static IXBaseServerContainer wss;  
  4.     public static void Start()  
  5.     {              
  6.         wss = XSockets.Plugin.Framework.Composable.GetExport();  
  7.         wss.StartServers();  
  8.     }  
  9. }  
  1. <p>Advantages:</p> 
  2. <ul> 
  3. <li>Seems powerful</li> 
  4. <li>Should have good JavaScript integration</li> 
  5. </ul> 
  6. <p>Disadvantages:</p> 
  7. <ul> 
  8. <li>Complicated and hard</li> 
  9. <li>Complicated to configure and run inside of WebForms, MVC and WinService</li> 
  10. <li>Differences between code and documentation</li> 
  11. <li>Outdated documentation and examples</li> 
  12. </ul> 
  13. </li> 
  14. <li> 
  15. <h2>Microsoft.WebSocket</h2> 
  16. <p><a href="http://msdn.microsoft.com/en-us/hh969243.aspx">http://msdn.microsoft.com/en-us/hh969243.aspx</a></p> 
  17. <p>Another library from Microsoft. And it requires IIS 8 too, so I did not have means to test it. Examples are really low level, so it force you to deal with buffers and streams instead of strings. In some cases this can be good, but mostly there is no point. If you have IIS 8 on server why bother with this library if you can use SignalR, which will take care most of the stuff for you.</p> 
  18. <p>I think this is more of proof-of-concept then usable library.</p> 
  19. <pre>int count = receiveResult.Count;  
  20.  
  21. while (receiveResult.EndOfMessage == false)  
  22. {  
  23.     if (count >= maxMessageSize)  
  24.     {  
  25.         string closeMessage = string.Format("Maximum message size: {0} bytes.", maxMessageSize);  
  26.         await socket.CloseAsync(WebSocketCloseStatus.MessageTooBig, closeMessage, CancellationToken.None);  
  27.         return;  
  28.     } receiveResult = await socket.ReceiveAsync(new ArraySegment(receiveBuffer, count, maxMessageSize - count), CancellationToken.None);  
  29.     count += receiveResult.Count;  
  30. } var receivedString = Encoding.UTF8.GetString(receiveBuffer, 0, count);  
  31. var echoString = "You said " + receivedString;  
  32. ArraySegment outputBuffer = new ArraySegment(Encoding.UTF8.GetBytes(echoString));  
  33. await socket.SendAsync(outputBuffer, WebSocketMessageType.Text, true, CancellationToken.None); 

SuperWebsocket

http://superwebsocket.codeplex.com/

最后但并不是最不重要的是SuperWebsocket。我对这个有一点怀疑（如果我没记错的话，这仅仅是一个我通过NuGet网站发现的包，但又不是一个可用的包）。它似乎有一点复杂，但实际上它是非常简单的。有文献支持的例子帮助你一步步的从最简单的WebSocket服务器，到有命令请求，JSON，多服务器实例，.config文件配置或者更多的复杂Websocket服务器。

这个库也许没有包含所有其他库有的那些很酷的特性，但是这没关系，因为它是高度可配置的，你可以很容易的让它实现你想要的。它可以作为控制台应用程序或者windows服务运行于ASP.NET中。文献上则建议以系统服务的形式来运行服务器。从我的经验来看，建议不要在一个web应用程序里面运行它因为这种解决方案很慢（非常糟糕的表现，比控制台应用程序大约慢50倍）。从另一方面，独立的服务器应用程序，需要运行.exe结尾的文件，这个文件并不是库的一部分，但是是SuperSocket项目的一部分（SuperWebSocket就是基于这个项目的）。这使得你需要一点技巧在调试会话中开启服务器，或者完全启用调试。当你作为应用程序运行服务器的时候，虽然这不是解决方案的一部分，也需要确保服务器采用来自其他项目的最新版的组件。

作为回报，你得到了关于灵活的WebSocket的众所周知的解决方案。

它仍然是开源的所以你可以根据需要改变它。

从另一方面，你可能把这个服务器缺乏JavaScript客户端看做是它的缺点（但是它有C#客户端）。这个服务器也有第三方的依赖关系。

在使用这个库工作了几个月之后我没发现什么主要的问题。

缺点和优点:

  • 无备用通信

  • 依赖

  • 优雅的特性和高度可配置性

  • 很棒的例子

  • 例子的都有推荐设置的文档

  • 可以作为windows服务和ASP.NET模块和控制台应用程序运行

  • 好的性能表现

总结

对于复杂的解决方案/项目我建议用SuperWebSocket，因为它是一个稳定而且高度可配置的库。对于简单和需要快速开发的项目我会选择Fleck，但是如果有办法使用最新的windows服务器来作为测试和生产机器的话，我会放弃使用这两个而选择SignalR。

posted @ 2017-08-03 13:33  从未被超越  阅读(537)  评论(0)  编辑  收藏  举报