0

さて、私の目標は、tcpを介してデータを送信するための使いやすいプロトコルを構築することです。基本的には、tcpを介してメッセージとオブジェクト(不明なタイプ)を送信します。送信するには1つのメソッド呼び出しのみが必要であり、受信するには1つのメソッド呼び出しのみが必要です。

これが私が「メッセージ」をフォーマットすることを考えていた方法です。

length_of_message-「メッセージである文字列」-length_of_Object-オブジェクト

length_of_messageは、設定されたバイト数になります。length_of_Objectとともに。

実際のメッセージ文字列と実際のオブジェクトは可変長になります。

オブジェクトの実際のクラスがわからない場合は、どういうわけか「汎用オブジェクト」として宣言できますか?次に、「汎用オブジェクト」からクラス名を取得すると、メッセージは受信者にオブジェクトをどう処理するかを通知しますか?

定数オブジェクトタイプであれば簡単ですが、送受信が必要なオブジェクトに対して、1つの送信関数と1つの受信関数を使用できるようにしたいと思います。

助言がありますか?

ありがとう、アンドリュー

4

1 に答える 1

2

車輪の再発明をしていないことを確認してください(そうすることが主な目標でない限り)。

それを念頭に置いて、次のことを考慮してください。

•NSCodingプロトコルを実装して使用します。これにより、サイクルを含む、複雑に接続されたオブジェクトグラフの効率的なアーカイブが可能になります。

•生のTCPの代わりに、HTTPを使用します。ヘッダーのオーバーヘッドが少し増えますが、本文はストレートエンコードされたデータにすることができます。さらに重要なことに、HTTPは至る所に存在します。他のプロトコルがブロックされる可能性があるのに対し、それはほぼすべてをルーティングします(プロキシサーバーを考えてください)。

•HTTPを介して、圧縮を活用できます。通信パイプの片側が何らかの既存のWebサーバーである場合、おそらくすでにgzipで圧縮された通信をサポートしています。NSDataの圧縮(NSCodingの結果)は簡単です。

•または、まっすぐなplistを使用します。

上記を実行不可能にする要件が本当にない限り、新しいテクノロジーを導入するのではなく、上記のテクノロジーを活用する方がよいでしょう。

そうは言っても、あなたが提案することは問題ありません。おそらく、次のような構造を追加します。

[HEADER] [MSGID] [LEN] [TYPE] [DATA of len] [POST]

POSTが既知のバイトシーケンスである場合、受信者は、おそらくすべてのデータが正しく受信されたことを確認するために検証できます。または、完全に独り占めしてチェックサムを統合することもできます。または、必要に応じてサブピースを繰り返すこともできます(つまり、[LEN][TYPE][DATA]を何度も繰り返すことができます。

于 2012-04-09T05:11:58.630 に答える