- ベストアンサー
TCP ロスがひどい時の対応
- みんなの回答 (2)
- 専門家の回答
質問者が選んだベストアンサー
原因を取り除くのが最優先だわな。 可能性としては 1.回線の物理的障害 2.トラフィックのオーバーロード 3.サーバー自体の異常 すべての正常なサーバーや端末、ルータにpingを飛ばして 応答がすぐに返されるものとそうでないものがあれば1の可能性がある。 そのサーバーに向かう回線に異常がある。 回線がNTTなど外部のものなら、調査をその会社に依頼する必要がある。 2.の場合もえてして多い。 同一セグメント内で他のユーザがLAN回線を通して、のべつまくなしCD等のコピーを やってたりとか。 この時はそのようなLANの使用をやめてもらうか、 スイッチングハブ等をあらたに導入するかですな。 3.の場合はサーバーの管理者に問い合わせるべし。
その他の回答 (1)
- okdummy001
- ベストアンサー率41% (5/12)
お礼
便利なページを教えていただきありがとうございます。 有用な情報がありそうなので、じっくり読んでみます。
関連するQ&A
- ソケットを使ったTCP通信
はじめまして. 最近ネットワークの勉強を始めた学生です. ソケットを使ったTCP通信について質問させてください. クライアント側はsocket(), connect()でコネクションを確立した後に何回か連続してsend(), recv()を行いたいのに,サーバ側がファイアウォールや侵入検知システムを使って途中で通信を終了するようにしてしまっている場合,クライアント側は再びコネクションを確立させなければ全てのsend()を行うことはできないのでしょうか? よろしくお願いします.
- ベストアンサー
- ネットワーク
- C++ TCP受信 突然切れる
C++のTCPソケット(recv関数)を使ってサーバからデータを定期的に受信する クライアントを作っているんですが、データの受信中?に突然TCP接続が 切れることがあります。 より正確にはrecvの戻りが0(sizeが0=切断された)になってしまいます。 物理的に配線が切れたとかでもなく、誰も手を触れず放置した状態のときに突然 切れたりとかわけが分かりません。 もしかしてTCPソケットって接続し続けてはいけないとかあるんですかね? 分かる人がいたら宜しくお願いします。
- 締切済み
- C・C++・C#
- TCP通信の切断の検出について
現在javaでTCP通信でサーバーに接続するタイプの大富豪を製作しております。 そこでTCP接続の切断の検出についてお聞きしたいです。 例えば既にあるオンラインのテーブルゲームなどをプレイしていると、誰かの通信が不安定になるor切断された場合、20~30秒程画面の間、動きが止まり、切断されたプレイヤー以外とのチャット等は可能で20~30秒後に誰かが「落ち」てプレイが続行されます。 この時、バックグラウンドではどのような処理が行われているのでしょうか? (1)TCP接続でデータの送信(受信)を行っているがとあるユーザーは切断されているのでそこが何度も送信(受信)のリトライ→反応なし(ACKを受信できず)→タイムアウトが20~30秒に指定してあり、時間経過後にタイムアウトが呼び出され切断されて続行される。 (2)通信が不安定なユーザーが居て切断/接続を何度も繰り返している。プログラム的に20~30秒不安定な状況が続けば切断するようなプログラムを組んでいる。 (3)その他 また、接続の切断の検出はサーバープログラムのどこで行われるのでしょうか。 (1)各接続クラスのInputStream.readもしくはOutputStream.write (2)Socket接続が切断されればどこかで例外が発生する? (3)その他 詳しい方居られましたら教えて頂けると幸いです。
- 締切済み
- Java
- winsockを使ったTCP及びUDP通信について
今回winsockを使った通信プログラムを組む事になったのですが、わからない点が多々ありましたので、どなたかご教授頂けると大変ありがたいです。 1. TCP通信において、送信側が"Hoge" "Fuga"と2回sendした際、受信側でrecvすると"Ho" "geFu" "ga"と3回受信する可能性があると認識しているのですが、これは正しいでしょうか? (到着する順序は保証されるが、recvする際に送信側がどのようにsendしたかは考慮されない) 2. UDP通信においては、上記のような現象は起きないと認識しているのですが、これは正しいでしょうか? (UDP通信では、2回sendすれば2回以上はrecvしない。パケットの破棄はあっても、分割はない) 3. もしUDP通信でも上記のような現象が起きる場合、到着順序の保証がされないという観点から、recvした際に"Ho" "ga" "geFu"と受信する事はあり得るのでしょうか? 4. 2が正しい前提での話です。UDP通信では、MTUを超えた場合、自動でパケットが分割されると聞きました。プログラムを組む際、これは意識しないといけないのでしょうか? (MTUが1500Byteの場合、UDPで2000Byteをsendすると、recvで1500,500と2回受信する?) 以上の4点です。 どなたかご存知の方いらっしゃいましたら、是非ご教授ください。
- 締切済み
- C・C++・C#
- TCP/IPのデータ送受信の"確実性"はどの程度??
Winsock2を使ってソケットプログラミングをするため通信プロトコルを考えています。そこでソケットの挙動について疑問があります。 sendを複数回使って以下のバイト数のデータを送信したとします。 1.3byte送信[AAA] 2.5byte送信[BBBBB] 3.3byte送信[CCC] このとき正常に通信ができたときは受信側では1~3回のrecvによって [AAABBBBBCCC] というデータが受信できると思います。ここまではいいのですが、疑問があるのは送受信に異常があった場合です。 1.send単位で欠落(再度connectの必要なし)。損失受信データ例[AAACCC]、[BBBBBCCC] 2.TCP上での送信パケット単位で欠落(再度connectの必要なし)。損失データ例[AAABB] 3.send単位で欠落して以後は全て欠落(再度connect必要あり)。損失データ例[AAABBBBB]、[AAA] 4.TCPのパケット単位で欠落して以後は全て欠落(再度connect必要あり)。損失データ例[AAABB] おそらくこれらのいずれかの方法でデータが欠落することになるかと思います。データの再送信をするのであればconnectが必要になるのかという点も分かりません。 ソケットがcloseになったという理由によるデータ欠落であれば4番になるかと思いますが。。。@FreeDのようにドーマントに入るようなネットワークの場合単純にcloseを期待することもできないような気がしますし。。。 どなたか教えていただけないでしょうか?よろしくお願いします。
- ベストアンサー
- C・C++・C#
- TCPのプログラミングで質問…というか確認しておきたいことが…
このたびC言語でネットワークプログラミング(TCP)をしているのですが、気になったことがあったので、2点ほど質問させていただきます。 (1)WSock32のsendで一度に送信できる量は65535バイトと以前学んだのですが、受信側がrecvする前にどんどん65535バイト送信していったら受信側のソケットはどんどんいっぱいになってしまいますよね?その場合、限界はあるのでしょうか?また、一度にrecvできる量も65535バイトが限界なのでしょうか?もしそうだとしたら65535バイト以上データがあると取得しても残ってしまうんですか? (2)sendで大きなデータなどを送信した場合、受信側でrecvしたときに途中までのデータを受信してしまったりすることってありますか?たとえば、「"abcde"と送信したのに対し、受信側でrecvしたらとりあえず"abc"まで受信し、次のrecvで残りのデータを受信する」様なことってあるんでしょうか? すべてのデータがちゃんと送信されてからじゃないとrecvで取得することはできなくなっているんでしょうか… とてもとても分かりにくい文章で本当にすみません。 すべてとはいいません、少しでも情報があれば教えていただけませんでしょうか・・・ どうぞよろしくお願いいたしますm(_ _)m
- ベストアンサー
- C・C++・C#
- 任意のTCPパケットを送信するプログラムの実装
TCP 通信確立後、任意のパケットを送信するプログラムを 作成しようと考えてます。ここでの任意のパケットとは、 下記のように TCP ヘッダの値を色々と設定したパケットを 指します。 ・TCP ヘッダのすべての制御フラグを有効にしたパケット ・TCP ヘッダのチェックサムを意図的に間違えたパケット 任意のデータを送信するだけであれば、通常の socket プログラムで実装できると思うのですが、TCP ヘッダを 色々と設定するプログラムとなると、どんな実装になるの でしょうか。C だと SOCK_RAW で socket 通信するよう、 実装するのでしょうか。 実装は C、perl を考えてます。
- ベストアンサー
- その他(プログラミング・開発)
- SocketのSend関数でのCLOSEの検知 [Linux]
Linux環境でSocket(dm:PF_INET,type:SOCK_STREAM)を使用しての、 Client&ServerプログラムをCで作成しているのですが、 そこでのSend関数の使い方についてご助力ください。 Client&Serverプログラムは下記のような動きをします。 [Client] ServerへConnectした後、複数のDataを数秒間隔でServerへ 送信(send関数使用)します。受信(recvやread関数等)は、 一切行いません。 [Server] ClientからのConnectを受け付けた後、Clientから受信(recv関数 使用)したDataを標準出力へ表示する。送信(sendやwrite関数 等)は、一切行いません。 さて、ここでもしClientプログラムがCloseを発行したり、マシン DOWN等の理由でConnectionが切断され、Server側のSocketが CLOSE_WAIT状態になった場合、Bufferに溜まっていたDataを すべて受けきった後、recv関数が0を返してくれるので 相手が終了したことがわかります。 ここからが質問のMainです。 では、もしServerプログラムがCloseを発行したり、マシン DOWN等の理由でConnectionが切断され、Client側のSocketが CLOSE_WAIT状態になっても、CLOSE_WAIT直後のsend関数が なぜか正常に処理されてしまいます。無論このDataは、 Server側は受け取りません。この次のsend関数実行時に EPIPEが返ってくるので、ここでようやくSocketが切断された ことが判ります。 これを何とかCLOSE_WAIT状態になった直後から、send関数で 切断を検知できるようにできないでしょうか。 よろしくお願いします。 以上
- ベストアンサー
- C・C++・C#
- ソケットプログラミングとスレッドについて
TCP/IPソケットを用いた通信プログラムを作成しています。その上でacceptする処理を専用スレッドにしており、accept後の受信処理をまた別のスレッドで処理しています。コンソールプログラムにおいてサーバとクライアントを用意しテストをしてみるとうまくいくのですが、MFCプログラムにおいて同じネットワーク処理を行ってみると、サーバ側へのconnectは成功するのですが、クライアント側からsendしたときにサーバ側でrecvの戻り値が必ず0にしかならず切断された状態になってしまいます。これはどういったときに発生すると考えられるでしょうか?ちなみにMFCが絡んでいるかどうかということは特にわかっておりません。 どなたかこのような経験をお持ちであればご教授お願い致します。
- 締切済み
- C・C++・C#
- TCPヘッダのヘッダ長について
誰か知っていましたら御教示ください。 TCPヘッダのヘッダ長は,通常5または6を使用するものだと考えてました 7を使用するのは,どのような場合でしょうか? なぜこのような質問するかは,以下のことをおこなって専用制御装置とPCでTCP/IPの通信が出来なくなっためです。 (1)PC側のOSを winNT→2Kへ変えたところ専用制御装置との通信断となりました。 (2)イーサアナライザで解析したらPCからのSYN送信にてTCPヘッダにおけるヘッダ長がNTの時は,6(24バイト)なのにwin2Kでは,7(28バイト)になった (3)専用制御装置側はTCPヘッダのヘッダ長7は,エラーと判定し通信しない設計になってました (4)PCのアプリはwinsockの単なるソケット通信 そのため,TCPヘッダを書き換えることはできません (5)おそらくOSがwin2Kになったことが原因だと思います。 win2KでwinNTの時のように SYN送信でTCPヘッダのヘッダ長を6にする方法は,あるのでしょうか? 大変恐縮ですが誰か御回答ください。
- ベストアンサー
- Windows系OS
お礼
回答ありがとうございます。 海外にあるサーバーとの話なのです。 なので通常時でも起こっているようなのです。