0

コマンドとして使用する値をネットワーク経由で転送する必要があり、可能な限り効率的かつ堅牢にしたいと考えています。つまり、これらのコマンドに何を使用するか、#defines または enumsについて意見が必要です。

コマンドの範囲は 20 コマンドを超えてはならない (コマンドに対して定義された応答ごとに 40 としましょう)。

これまでのところ、最良のアプローチは列挙型を使用することだと思います。

4

4 に答える 4

1

行区切りのテキストベースのプロトコルを使用することもお勧めします。enum-vsについて心配する必要がないことは別として。#define値には、他にもいくつかの利点があります。

ハッキング/テスト

テキストベースのプロトコル用の一連のコマンドを手動で生成するのは非常に簡単です。HTTP サーバーでエラー条件をテストすることを検討してください。

$ telnet www.yahoo.com 80
Trying 69.147.76.15...
Connected to www-real.wa1.b.yahoo.com.
Escape character is '^]'.
GOAT / HTTP/1.1

サーバーがどのように応答したかを理解するのに、特別なことは必要ありません。

HTTP/1.1 400 Bad Request
Date: Sat, 11 Jul 2009 16:20:59 GMT
Cache-Control: private
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html; charset=iso-8859-1

これはデバッグに最適です。telnet/にフィードする一連のテスト スクリプトを作成できますnc。これらは、バイナリ プロトコルのテスト スクリプトよりも保守がはるかに簡単です。

携帯性

プロトコルを ASCII テキスト (または UTF-8) で定義すると、新しいプラットフォームでの低レベルの問題について心配する必要がなくなります。バイナリ プロトコルを扱う場合、エンディアン、構造のアライメント、およびワード サイズはすべて問題になります。ASCII では、追加のシリアライズ/デシリアライズの手順が必要になる場合がありますが、ネットワーク プロトコルでは、とにかく一般的に必要です。

共有

プロジェクトで他の人と共同作業したい場合は、ネットワーク操作を平文で説明できると便利です。他の誰かが独自のクライアントを開発したい場合、ヘッダー ファイルなどを使用する必要はなく、RFC のような標準に準拠する必要があります。これはペットのプロジェクトには役に立ちませんが、大きくなる可能性があるものについて考慮することは良いことです。

于 2009-07-11T16:30:21.657 に答える