go.net/websocketパッケージにはRead()、Write()Web ソケットを介してメッセージを送受信するための関数が含まれています。代わりに、メッセージを送受信するためのチャネルを返さないのはなぜですか? などのパッケージは、go のチャネルを使用するのに最適な場所だと思いwebsocketますnet。この設計上の決定の背後にある理由は何ですか?
1 に答える
2
WebSocket の正確なセマンティクスはわかりませんが、一般的に、ネットワーク ソケットはチャネルにうまくマップされないと思います。実際、チャンネル全般でこれを行おうとした netchan パッケージがありましたが、廃止されました。
1 つのチャネルの実装で多くのプロトコルをサポートしようとすると、多くの問題があると思います。メッセージはどこで始まり、どこで終わりますか? チャネルは大きなメッセージをバッファリングする必要がありますか、それともチャンクごとに与える必要がありますか? 各プロトコルのセマンティクスは大きく異なるため、Go は、他の言語で見られるように、ソケットの下位レベルの読み取り/書き込みを提供し、データの処理方法を決定するのはユーザーに任せます。
ソケットチャネル全般について話していることに注意してください。WebSocket は明確に定義されたプロトコルであり、チャネルを使用した実装が適切に機能する可能性があります。チャンネルが選ばれなかった理由については、 ( Google グループをgo.net/websocket試してみてください) の作成者に尋ねるのが最善でしょう。golang-nuts現在の API は通常の Go ソケット API に似ているため、ある意味では理にかなっていると思います。
チャネルを使用しなくても、API が非並行になるわけではないことに注意してください。接続が別々のゴルーチン (Go の HTTP サーバーではそうです) で処理されている限り、それらは同時に処理されます。チャネルを使用するかどうかは、ここでは便宜上の問題です。
于 2013-08-30T08:50:17.790 に答える