- 締切済み
フロー制御について
勉強中の初心者です 質問なのですが、連続した4つのセグメントが送られた時、 1,2,4番目のセグメントに対するACKが送信途中に破棄されたとします。 すると、3番目のセグメントに対するACKが最初に届くと思うのですが、 4番目は置いといて、5番目、6番目のセグメントを先に送信します。 その後、一定時間待っても4番目のセグメントに対するACKが返ってこないので、再送信しますよね？ その後、相手側は6番目のセグメントに対するACK(7番目を要求)を送信した後、4番目が遅れて到達します。 この時、4番目のセグメントに対するACKも、7番目のセグメントを要求する と読んだのですが、この時なぜ、一度要求したセグメントと同じもの を要求するのでしょうか？ ただ単に、ウインドウのサイズの更新的な意味合いからでしょうか？
- hamachi7
- お礼率89% (35/39)
- その他（インターネット接続・通信）
- 回答数2
- ありがとう数1
- みんなの回答 （2）
- 専門家の回答
関連するQ&A
- パケット通信の再送制御についての質問です。
パケット通信の再送制御についての質問です。 再送制御の説明を色々なサイトで見つつ思うのですが、ｎ番目のパケットがエラーだった時に、ｎ番目から送り直すのは何故ですか？ｎ＋1番目、n+2番目はエラーじゃないのに破棄するのが勿体ない様に感じます。n番目のパケットだけ後から要求すれば良い様に思うのですが、何故そう出来ないのでしょうか？ また、再送制御の説明で受信側と送信側を数フレーム分ずらして説明が書いてある理由は何なのでしょうか？１フレームの間に再送要求をしてしまえない物なのでしょうか？ ご存知の方がいらっしゃいましたら教えて頂けませんでしょうか？ 宜しくお願い致します。
- 締切済み
- 科学
- FIN,ACKとACKについて
はじめまして。5月よりTCPソケット通信を勉強しているものです。 クライアントとサーバーのプログラムを作り試行錯誤しながら動かしているのですが一つ不思議な現象が起きたので質問させて頂きます。 処理が終わり、通信を切断する時なのですが、ソケット通信に関連する書籍やWebページを見ていると接続を切断するときにFIN,ACKを送信して相手側がACKを送信し、FIN,ACKを送信して最後にACKを送信するとなっています。図にすると以下のような感じでしょうか。 PCA PCB FIN,ACK送信 → FIN,ACK受信 ACK受信 → ACK送信 FIN,ACK受信 → FIN,ACK送信 ACK送信 → ACK受信 この手順でPCA,PCBともに切断されるとあるのですが、自分が作ったプログラムを実行させて、etherealでパケットをモニタリングすると以下のような状態で終わってしまいます。 PCA PCB FIN,ACK送信 → FIN,ACK受信 FIN,ACK受信 → FIN,ACK送信 ACK送信 → ACK受信 PCAからのFIN,ACK受信に対してのACKの送信が省略されて、いきなりFIN,ACKを送信してしまいます。その後PCAからはACKが返されて終了となります。 プログラム的には希望通り動作しているので問題は無いのですが、なぜ途中のACKが省略されてしまうのか原因が知りたいです。また、自分の認識が間違っている場合のご指摘等頂ければと思います。 つたない文章で申し訳ありませんがご存知の方がいらっしゃいましたら教えて下さい。
- 締切済み
- ネットワーク
- TCPヘッダにある確認応答番号とウィンドウサイズについて
はじめまして。 質問があります。 参考書によると、 送信側のトランスポート層で作られたセグメントを受信側の同層で 受け取ったとき、そのセグメントに付加されているTCPヘッダ内の 確認応答番号と、ウィンドウサイズは、受信側で書き込むらしいの ですが、どういうことなのでしょうか？もしかしたら、受信側が 送信側に送る確認応答のヘッダは、送信側でセグメントに付加した TCPヘッダを使いまわしているという解釈でよろしいのでしょうか？ わけがわかりません。どうかご教授お願いします。
- ベストアンサー
- その他（インターネット接続・通信）
- データベースの初心者からの愚問です。
Oracleの参考書を初めて読ませて頂いた時に、 次の疑問にぶつかりましたから、教えて頂けますでしょうか？ VLANの機能が搭載されていないルータの配下に、 其処のDHCPサーバのセグメントとは違うIPアドレスのPCを置いている場合にも、 ループバックは可能なのだろう、と思われますが、 そのループバックは、WAN側へ出て行った後に行われているのでしょうか？ その書籍の中には、"10.10.10.10:1521"番のIPアドレスの固定の必要性が記載されていましたので、VLANの知識さえもが乏しい私の拙い理解では、 違うセグメントのIPアドレスのPCからの送信がルータでブロックされまいか、 と思われまして、その段階で、引っ掛かってしまいました。
- ベストアンサー
- Oracle
- ■FWのフィルター設定で、特定のIPセグメントのPCのみ、通過できるような設定にしたいのですが、、、
【設定】 FWのフィルター設定で、特定のIPセグメントのPCのみ、通過できるような設定を行いたいと思っています。 【質問】 例えば、10.10.10.0/24セグメント上のPCの通信からのみ通過させたい場合、以下A,B,Cの設定のどれでしょうか？ A：送信元IP＝10.10.10.0-10.10.10.255 の通信を通過。 後はすべて破棄。 B：送信元IP＝10.10.10.1-10.10.10.254 の通信を通過。 後はすべて破棄。 C：どちらでもOK。 【聞きたいポイント】 10.10.10.0はネットワークアドレス，10.10.10.255はブロードキャストアドレスなので、 それが発信元にならないかと思うので、Bで問題ないでしょうか？ それとも、普通はAにするのでしょうか？
- ベストアンサー
- ネットワーク
- ソケット通信の送受信遅延-02 その後
前回のNo.1031658 「ソケット通信の送受信遅延」に追加させてもらいます その後、プロトコルアナライザで現状調査を行い以下の現象を確認しました ◇正常時 サーバがメッセージ送信 TCPヘッダ内フラグ ACK:1, PSH:1 + 送信データあり ↓ 0.2msec前後で クライアントが 返信 TCPヘッダ内フラグ ACK:1, PSH:1 + 返信データあり ↓ 10msecで サーバが送信 TCPヘッダ内フラグ ACK:1, PSH:1 + 送信データあり ↓ 0.2msec前後で クライアントが 返信 TCPヘッダ内フラグ ACK:1, PSH:1 + 返信データあり ↓ 以下繰り返り ◇不具合時 サーバがメッセージ送信 TCPヘッダ内フラグ ACK:1, PSH:1 + 送信データあり ↓ 0.2msec前後で クライアントが 返信 TCPヘッダ内フラグ ACK:1, PSH:1 + 返信データあり ↓ 10msecで サーバが送信 TCPヘッダ内フラグ ACK:1, PSH:1 + 送信データあり ↓ 約130msec前後で クライアントが 返信 TCPヘッダ内フラグ ACK:1, PSH:0 + 返信データなし ↓ 約250msec前後で クライアントが 返信 TCPヘッダ内フラグ ACK:1, PSH:1 + 返信データあり ↓ といった状況です どう解釈すれば良いのでしょうか 遅延の原因はソケットなのかそれ以外なのでしょうか？是非アドバイスをおねがいします。
- 締切済み
- C・C++・C#
- 情報通信の問題なのですが・・・
情報通信の問題なのですが・・・ 回線速度Ｃ（ビット/秒）の専用全２重回線を用いて、ホストＡからホストＢへ固定長ＬＤ（ビット）のパケットを stop-and-wait ARQプロトコルと呼ばれる以下の手順に従い伝送することを考える。 ホストＡはパケットを一つ送信した後、ホストＢからのＡＣＫを持つ。 もし、送信後、タイムアウト時間Ｔ（秒）以前にＡＣＫを受信すれば、直ちに次のパケットの送信を行う。 一方、送信後、タイムアウト時間ＴまでにＡＣＫを受信しなければ、送信は失敗したとみなし、再送する。 ホストＡは先行するパケットに対するＡＣＫを受信するまで後続のパケットの送信を開始しないことに注意する。 他方、ホストＢはパケットを正しく受信した場合、直ちにホストＡへ固定長ＬＡ（ビット）のＡＣＫを送信する。 また、受信したパケットに誤りがある場合はそれを破棄する（ＮＡＫは送信しない） なお、誤り検査に必要な時間は無視できると仮定する。 ホストＡとホストＢの間の往復伝播遅延をＲ（秒）とする。 ホストＡから送信された任意のパケットに対するＡＣＫをホストＡが受信する確率を1-ｐ（0＜ｐ＜1）として、以下の問いに答えよ。 （i）ホストＡがパケット送信後、タイムアウトが起こる前に、送信したパケットに対するＡＣＫを受信したとする。 このとき、ホストＡがこのパケットの最初のビットを送信してからＡＣＫの最後のビットを受信するまでの時間Ｓ（秒）を求めよ。 Ｔ＞Ｓと仮定する。 （ii）ホストＡが一つのパケットの送信を開始してから最終的にＡＣＫを受け取るまでに必要な時間の平均Ｈ（秒）を、 Ｓ、ｐならびに以下で求められるＦを用いて表せ。 Ｆ＝ＬＤ/Ｃ+Ｔ （iii）ホストＡには常に送信待ちパケットがあると仮定する。 このとき達成される最大スループットθをＨを用いて表せ。 ただし、スループットとは１秒当たりの平均送信成功パケット数を指す。 どなたかご解答をよろしくお願いします
- ベストアンサー
- 情報処理技術者
- 排他制御の方法
現在、PWS+ASP+ACCESSを使用し開発を行っていますが排他制御で悩んでいます。 ASPは、ステートレスなセッションでの制御しか出来ないため、ページを表示後のデータの変更はスタンドアロンでの更新のような形になってしまうと思います。 以下のような方法で行っている実例を見たことがありますが、少なからず問題も抱えていると思います。 ・レコード毎に排他フラグを保持する ～ 処理がアベンドした場合にフラグが残る（一定時間後に解除という方法もありますが） ・レコード毎に更新時間を持ち、読込時の更新時間と更新時の更新時間とを比較し更新されていない時だけ更新をかける ～ 後に更新をかけようとした変更が無駄になる 上記の方法以外で、排他制御を実現させる良い方法はないのでしょうか。他の方法で実現しているときは、その方法を教えて頂けませんでしょうか。 ※PWS→IIS、ACCESS→SQLServerに変更する可能性はあります。 （セッションオブジェクト・アプリケーションオブジェクト等を使用しての実現方法など） 宜しくお願いします。
- 締切済み
- Microsoft ASP
- WinsockによるUDP通信にて
WinsockでUDP通信を行うプログラムを作っているのですが、 原因不明の問題が発生していて困っています。 通信手順は以下のとおりです。 (1) クライアントからサーバへ要求パケット送信 (2) 要求パケットを受け取ったサーバは、クライアントへACKを送信 (3) サーバが要求に対する応答パケットをクライアントへ送信 (4) 応答パケットを受け取ったクライアントは、サーバへACKを送信 クライアント－サーバ間でやりとりするデータは最大で９９２バイト、 それ以上になる場合は、分割して送信します。 パケットの分割が発生しない場合は、(1)～(3)がパケットの損失もなく通信できるのですが、 パケットの分割が発生する場合には、2回目以降の(4)のパケットがクライアントに届きません。再現率は今のところ100％です。 クライアント側のselect関数でもソケットを検出しません。 たしかにUDPは信頼性が低いですが、パケット分割が発生しないパターンでは100％届くので、UDPの仕様とは関係ないような気がします。 原因がさっぱりわからないので、アドバイスをお願いいたします。 ちなみに、クライアント、サーバともに同一端末内にあります（双方がループバックアドレスに対してパケットを送信）が、 これはテスト段階だからであって、本来はそれぞれ別々の端末で動作します。
- 締切済み
- C・C++・C#
お礼
semikumaさん、回答ありがとうございます ウインドウサイズを大きくして、例えば4つのセグメントを送信する場合は、 4つとも送信が成功した場合のみACKが返ってくるという事ですよね？ それで、ACKが返ってこない理由が何であろうが、送信成功が確認できない場合は、ウインドウサイズを小さくして再度送信という事ですよね 私が読んだ内容は初心者向けのものだったので、内容をわかりやすくして書かれていたのかもしれません。 どうもありがとうございました