• 締切済み

TCP/IP通信(ソケット通信)について

開発者新人です。 この度、TCP/IPのソケット通信を使ったWindowsアプリケーション開発(クライアント/サーバ)を 行います。 過去にシリアル通信の開発経験はありますが、ソケット通信の開発は初めてです。 そこでSEの皆さんにぜひご教示頂きたいのですが、設計をする上での 標準的な設計事等あると思いますが、どういう観点にて設計していきますでしょうか。 また、ソケット通信を行う際、コマンドフォーマットを決めるかと思います。 用途に応じて様々かも知れませんが、標準的なフォーマットはどういうものでしょうか。 (例) コマンドID、サイズ、データ部、サム。 シリアル通信のようにSEX、ETX等のヘッダは必要? 再送、タイムアウトの考え方等々。 変な質問内容になりましたが、宜しくお願いします。

みんなの回答

回答No.2

シリアル通信と比較した場合の注意をひとつ。 パケット関係の通信を利用した場合の注意点として、 送信側がデータを送信した場合でも、 それが、ルーター等に滞留して、受信側に到達していない期間が生じる。 この期間にネット障害が発生すると、滞留データが消失する。 その結果受信側ではデータ未受信、送信側では送信済み という不整合が生じる。 これを、避けるためには、アプリケーションレベルでの 「データ・コンファメーション」が必要です。 すなわち、 送信側で最終データを送信したら、 受信側で最終データを受けたという確認メッセージを送信し、 送信側でこの確認メッセージを確認したのち、送信済みフラグを立てる という処理にせねばなりません。 まあ、このようなアプリケーションレベルのコンファメーションが 必要となります。(いわゆるバッチ伝送の場合ですが) それから、あたり前のことですが、そのプログラム処理の場合 オペレータが常に監視しているか、全くの無人伝送システムかによって アプリケーションレベルのプロトコルは大きく異なりますので よろしく。

  • nda23
  • ベストアンサー率54% (777/1415)
回答No.1

先ず、ソケット通信にはストリーム型とデータグラム型の 二つがあります。どちらを使うかで、かなり差が有ります。 また、プロトコールが決まっていると思いますので、 「>コマンドフォーマットを決める~」というような発想には なりません。既に決まりごとがあるからです。また、 ヘッダやチェックサム等は織り込み済みですので、 単にデータ部分だけ考えればよいようになっています。 細かいものが見たければWireSharkなどを入れれば、 制御部も含めたデータが覗けます。 ということで、既存プロトコールを流用する方が簡単です。 独自プロトコールを創設してもよいのですが、メンドウだし、 メリットが殆どないと思いますよ。 基本はFTPなので、これのクライアント側のプログラムを 作ってみるとよいでしょう。クライアントサイドでも大量の データの受け渡しをする場合はデータ用チャネルを作り ます。この時サーバ側と同じ動作をしなければならない ので、両方の動作が学べます。 あと、Windows上でのプログラムであるなら、非同期の 割り込み方式を使うべきです。これは受信において、自ら 受信するのではなく、ウィンドウに受信があったことを通知 してもらうやり方です。通知を受けて始めて受信を開始する 方法です。ポーリング(自分で受信データの有無を調べる 行為)は論外です。また、Windowsでのタイマの使い方も 二通りあり、どちらを使っても良いでしょう。制限時間は パラメータファイルからの読み込みなどで決めるようにすると 便利になると思います。

関連するQ&A