Q&A
TCPを切断しないならずっと接続状態にするってことで、それでなぜ通信情報を引き継ぐという話になる？
質問内容がいまいちわかりません
C#(Windows環境)にて以下のようにサーバAから別ネットワークのサーバCへ
情報電文を送信するシステムの構築を検討しています。
サーバA （1分毎にデータ取得）
↓UDP （取得データ送信）
サーバB （受信データチェック）
↓TCP （受信データ送信）
サーバC
この際、サーバB-C間の通信APはUDP受信をWindowsサービスで監視し、
受信の都度起動する想定ですが、初回起動時からTCP通信はcloseせず
持続したいと考えています。
初回起動時にconnectした通信情報を次回起動時に引き継いで
利用する方法があればご教授頂きたいです。
また、上記が難しい場合サーバB-C間の通信APを常時起動することと
なるかと思いますが、UDP受信をトリガーに待機中処理を開始する方法が
あればご教授頂きたいです。
自身でも調査していますが解決策が見つかっていない状況です。
宜しくお願いします。
TCPについての勉強不足で仕組みが分かっておらずとんちんかんな内容になってたら申し訳ないです。
①サーバBでUDP受信（初回）
②通信AP起動
③TcpClientのコンストラクタでconnectしてその情報をNetworkStreamに渡し、WriteでデータをサーバCに送信する
④closeせずに通信APを終了する
⑤サーバBでUDP受信（２回目）
⑥通信AP起動
この時通信状態を確認して通信済みであればconnectせずにWriteのみ行いたいのですが、TcpClientをインスタンス化した際コンストラクタでconnectが実行されて2重接続とはならないんでしょうか？初回でconnectした接続を使ってWriteのみ行うようなことが可能かが知りたいです。
TcpClientを生成し、Connectしたならそれをずっと使えばいいのです
TcpClientを生成しなおすとかConnectしなおすとかする必要はありません
起動しっぱがもったいないというなら、その都度接続しましょう
回答ありがとうございます。調べてみても私の検討している実現方法は一般的なＴＣＰの使い方ではないのですね。常駐プログラムで設計を再検討してみます。
回答1件
0
ベストアンサー
サーバBでUDPポートの受信待機をしているプロセスは、サーバAからの指示がない限り動作させ続けるのが良いと思います。
サーバAからサーバBのUDPポートにデータが届いた事を監視しているプロセスは、ずっと監視を続けている必要がありますから、毎回停止させるのは不合理だと思います。
サーバBでUDPポートを監視しているプロセスが、サーバCとのTCPコネクションを保持しているなら、TCP通信を継続的に利用するのに好都合です。
こういう雰囲気でシステムの構成を考えられませんか？
投稿2019/04/02 08:17
総合スコア6915
回答ありがとうございます。常駐プログラムで設計を再検討してみます。
y_waiwaiさんは回答欄でなく指摘欄でしたのでcoco_bauerさんの回答を
ベストアンサーに選ばせて頂きます。
あなたの回答
tips
プレビュー
