|
>>4713 榊 > ・送受信処理のJavaの実装例 送受信の基礎は echo クライアント・サーバや http クライアント・サーバの 実装サンプルを探せばよいでしょう。 データ受け渡しは、http のパラメータで渡す・CSV・XMLRPC・SOAP など実現 方法はいろいろあるでしょうが、それは開発スピードや保守性に関わる部分 なので、はっきり言って何でもいいです。 > ・送受信が１秒間に100回あってもレスポンス悪化しない方法 > （100回という数値は適当です。普通どれくらいを目標にするのですか？） 要件次第です。相手側は何箇所あるのか、MAX で 1秒あたり何回送信する 可能性があるかを考え、安全係数 (1.5 とか) をかけて、それをさばける 構成を考えます。 高速化方法は、https の上に載せるのであれば一般的な web のパフォーマンス チューニングがメインとなるでしょう。 - web サーバチューニング - SSL アクセラレータ導入 - DB チューニング・コネクションプール - web サーバ複数台化 > ・通信エラー等の例外処理の実装方法 > （通信エラー発生時の電文はロストするのですか？それってどうリカバリー > するのですか？ その当たりに関する事） ロストする可能性があると考えて設計した方がよいでしょう。 プロトコル的には 1. A -> B データ送信 2. B -> A 完了通知 これだけだと思いますが、アプリの手順まで含めると 1. A -> B データ送信 2. B にて受信済フラグセット 3. B -> A 受信完了通知 4. A が受信完了通知を受け、送信済フラグをセット となると思います。で、 - A は送信済フラグが立っていない場合は再送する - B が既に受信済フラグを受けていたら、無視 or 破棄する などの対処をすると。もし即時の再送がまずいなら、 0. A にて送信日時をセット 1. A -> B データ送信 2. B にて受信済フラグセット 3. B -> A 受信完了通知 4. A が受信完了通知を受け、送信済フラグをセット として、「前回送信から n分経過していたら再送する」などの仕組みも必要と なるでしょうが、その辺は要件次第です。 もちろん、ブラウザのように 「タイムアウトしたらエラー通知するだけ。再送は操作者まかせ」 というのも選択肢としてはアリです。 > ・「なりすまし，盗聴，改ざん」っといった事に対する防御方法とその実装方法に関する事 その辺は SSL でカバーするのがよいでしょう。相手側のなりすましも 防御する必要があるならクライアント証明書を使うとか、アプリレイヤで 認証するとか、固定 IP アドレスなら IP アドレスで制限をかけるとか。 もしネットゲームのように不特定多数が接続し、しかも送信プログラムを 改ざんされる恐れがある場合は大変面倒です。 |