ウェブプロジェクトでは、必要に応じてクライアントのリクエストを待たずに、できるだけ早くクライアントにデータをプッシュする必要があることがよくあります。双方向通信メカニズムは、オンラインコミュニケーションやドキュメントコラボレーションツールのようにリアルタイムでユーザーと通信するサイトや、長時間稼働する計算/実行タスクサーバーのシステムステータスを更新する場合などに最適です。
以前は、この種の問題には次のような解決策が用いられていました。
Flashでソケット接続を使う
Ajax
サーバーがイベントを送信...
または、IE[]で古典的なフレームテクニックを使うこともできます。
WebSocketの標準規格は2011年にリリースされ、しばらく前からモダンブラウザに実装されています。より安全で成熟したプロトコルを使用しているため、改善やアップグレードが行われ、より優れています。
注意事項
この比較は数ヶ月前に行われたもので、最新ではないかもしれませんが、もし誰かが良いWebSocketライブラリを探しているのであれば、これはまだ役に立つと思います。
SuperWebSocket は NuGet のリポジトリを使用しますが、Web ページからダウンロードする必要があります。
時間ができたら、新しいライブラリやテスト済みのライブラリの新しいバージョンを使って比較し、この記事を更新したいと思います。
フレック
ライブラリを追加し、サンプルのコードを数行コピーして実行するだけです。
しかし、シンプルさには代償が伴います:あまりパワフルではなく、設定できる場所が少なすぎるのです。
private static void Main(string[] args)
{
var server = new WebSocketServer("ws://localhost:8181");
server.Start(socket =>
{
socket.OnOpen = () => OnOpen(socket);
socket.OnClose = () => OnClose(socket);
socket.OnMessage = m => OnMessage(socket, m);
});
}
私はシンプルで迅速なプロジェクトに使いますが、複雑すぎるデータ構造やコマンドのようなメッセージを送信するためにWebSocketを使用する必要がない場合、またはクライアントがWebSocketをサポートしていない場合の代替手段として、これはあなたが望むものです。
長所。
シンプル
依存関係なし
デメリット
設定可能性が低い
WebSocketをサポートしていないクライアント・ブラウザは役に立ちません。
シグナルR
マイクロソフトは、このライブラリの一番の魅力だと思います。すでに既存のASP.NETフレームワークと統合されており、サーバーサイドとクライアントサイドのコードの両方に素晴らしい抽象クラスを持っています。クライアントブラウザがWebSocketをサポートしていない場合は、自動的に他の通信メカニズムを使用することもできます。また、サーバーからクライアントへのリモートプロシージャコールと呼ばれることもできます。
すべてのクライアントにメッセージをブロードキャストすることも、特定のユーザーに個別にメッセージを送信することもできます。また、大量の同時接続の処理にも優れています。しかも、オープンソースです!
いい感じでしょう?でも...IIS8かWindows Server 2012が必要です。IIS8かWindows Server 2012が必要で、私にとっては「マイクロソフトの新世代OSは買う価値がある」という超クールな機能です。エンタープライズ・プロジェクトを開発するのであればいいのですが、小規模なプロジェクトでは、このオープンソース・ライブラリのためにOSを買うのは高すぎます。
もちろん、これらの環境はWebSocketに必要なものです。 この記事はWebSocket通信について書いているので、これは大きな欠点としてカウントしています。
public class MyHub1 : Hub
{
public void Send(string name, string message)
{
// Call the broadcastMessage method to update clients.
Clients.All.broadcastMessage(name, message);
}
}
$(function () {
var chat = $.connection.myHub1;
chat.client.broadcastMessage = function (name, message) {
//...
};
$.connection.hub.start().done(function () {
$('#sendmessage').click(function () {
chat.server.send('message');
});
});
});
長所。
とても素晴らしい抽象化
IISとASP.NET緊密な統合
候補となるアプローチ
オープンソース
マイクロソフト公式ライブラリ
優れたスケーラビリティ
デメリット
IIS8が必要ですが・・・。
... Windows Server 2012は高すぎます。
#p#
AlchemyWebSocket
ウェブソケット・ライブラリといえば、このライブラリ。そうなんです。Fleckの後塵を拝し、非常に使いやすく、インストールも簡単で、ドキュメントには素晴らしいサンプルが含まれています。
サーバーサイドとクライアントサイドの両方のコンポーネントを含み、スケーラブルです。
static void Main(string[] args)
{
// 创建一个新的server - 接受端口和ip范围,
// セットアップ方法
var aServer = new WebSocketServer(81, IPAddress.Any)
{
OnReceive = OnReceive,
OnSend = OnSend,
OnConnect = OnConnect,
OnConnected = OnConnected,
OnDisconnect = OnDisconnect,
TimeOut = new TimeSpan(0, 5, 0)
};
aServer.Start();
string consoleReadLine;
do
{
consoleReadLine = Console.ReadLine();
sockets.ForEach(s => s.Send(consoleReadLine));
} while (consoleReadLine != "exit");
}
しかし、これには避けられないひねりがあります。例えば、単純なイベント・メソッド "OnReceive "はなく、文字列だけです。自分でやらなければなりません。そう、実際のメッセージを取得するためには.ToString()を呼び出す必要があり、呼び出すことしかできません。
private static void OnReceive(UserContext context)
{
Console.WriteLine("Client " + context.ClientAddress.ToString() + " sended: " + context.DataFrame.ToString());
}
WebSocketサーバーの初期化メソッドでは、最初にポート、次にIPの設定を受け取ります。アドレスはIP→ポートの順で表現し、ポートを指定する必要がある場合のみ指定するべきだと私は常々考えています。タイムアウトの設定もあります。タイムアウトが便利な場合もあることは理解できますが、機能として主要な設定の1つにすべきではないでしょう。もちろん、これは単なる詳細です。
これでは、そもそもこのライブラリを通して、別のレイヤーのコードで抽象化せざるを得ません。
とにかく試してみて、Fleckと性能を比較し、シンプルなプロジェクトではどちらが優れているかを判断してください。
アドバンテージ:
シンプル
依存関係なし
ドキュメントが充実
欠点:
フレックの構成に比べると、ちょっと不便で複雑です。
フォールバックなし
ソケット
このライブラリーは期待できそうです。私はそれを試してみましたし、他のライブラリよりも多くの時間を費やしました。しかし、残念ながら私は運がありませんでした。私が考えたどんなエラーも、このライブラリでは間違っており、コードと一致しない悪いドキュメントでした。コードやドキュメントが古いからでしょうか?実際、私はこのライブラリのサンプルを立ち上げて動作させるのに苦労しました。xsocketはMVCフレームワークがどのようなものかをもっと示しています。ASP.NETプロジェクト、MVC、WinServiceで動かしてみましたが、残念ながらどれも動きませんでした。
本当はこのライブラリを使いたかったのですが、より良いライブラリをサポートするためにあきらめました。真面目な話、なぜ簡単なプロジェクトでさえこのライブラリを使うのが難しいのでしょうか。プロジェクトでこのライブラリを使用すると、さらに多くの問題が発生することが予想されるので、このプロジェクトは避けることを強くお勧めします。
public static class XSocketsBootstrap
{
private static IXBaseServerContainer wss;
public static void Start()
{
wss = XSockets.Plugin.Framework.Composable.GetExport();
wss.StartServers();
}
}
<p>Advantages:</p>
<ul>
<li>Seems powerful</li>
<li>Should have good JavaScript integration</li>
</ul>
<p>Disadvantages:</p>
<ul>
<li>Complicated and hard</li>
<li>Complicated to configure and run inside of WebForms, MVC and WinService</li>
<li>Differences between code and documentation</li>
<li>Outdated documentation and examples</li>
</ul>
</li>
<li>
<h2>Microsoft.WebSocket</h2>
<p><a href="http://..com/en-us/.aspx">http://..com/en-us/.aspx</a></p>
<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>
<p>I think this is more of proof-of-concept then usable library.</p>
<pre>int count = receiveResult.Count;
while (receiveResult.EndOfMessage == false)
{
if (count >= maxMessageSize)
{
string closeMessage = string.Format("Maximum message size: {0} bytes.", maxMessageSize);
await socket.CloseAsync(WebSocketCloseStatus.MessageTooBig, closeMessage, CancellationToken.None);
return;
} receiveResult = await socket.ReceiveAsync(new ArraySegment(receiveBuffer, count, maxMessageSize - count), CancellationToken.None);
count += receiveResult.Count;
} var receivedString = Encoding.UTF8.GetString(receiveBuffer, 0, count);
var echoString = "You said " + receivedString;
ArraySegment outputBuffer = new ArraySegment(Encoding.UTF8.GetBytes(echoString));
await socket.SendAsync(outputBuffer, WebSocketMessageType.Text, true, CancellationToken.None);
スーパーウェブソケット
***しかし、最も重要なのはSuperWebsocketです。少し複雑そうに見えますが、実際はとてもシンプルです。最も単純なWebSocketサーバーから、コマンドリクエスト、JSON、複数のサーバーインスタンス、.configファイルの構成などを持つ複雑なWebSocketサーバーまで、ステップバイステップで支援するための文書化されたサポート例があります。
その見返りとして、柔軟なWebSocketに関する有名なソリューションを得ることができます。
オープンソースなので、必要に応じて変更することができます。
裏を返せば、このサーバーにはJavaScriptクライアントがないことが欠点と言えるかもしれません。また、このサーバーにはサードパーティの依存関係があります。
数ヶ月間このライブラリを使ってみて、特に大きな問題は見つかりませんでした。
短所と長所。
スタンバイ通信なし
依存関係
エレガントな機能と高度な設定可能性
素晴らしい例です。
推奨設定の文書があります。
Windowsサービス、ASP.NETモジュール、コンソールアプリケーションとして動作します。
優れたパフォーマンス
概要
複雑なソリューションやプロジェクトには、安定していて高度に設定可能なライブラリであるSuperWebSocketをお勧めします。シンプルで迅速な開発が必要なプロジェクトにはFleckを使いますが、もし**** Windowsサーバーをテスト用と本番用のマシンとして使う方法があれば、SignalRを使うために両方を使うのをあきらめます。