ネットワークプログラミング相談室 Port24
■ このスレッドは過去ログ倉庫に格納されています
0001lmtp
2009/07/07(火) 00:46:28Programming UNIX Socket FAQ (日本語訳)
http://www.kt.rim.or.jp/~ksk/sock-faq/indexj.html
Winsock Programmer's FAQ (日本語訳)
http://www.kt.rim.or.jp/~ksk/wskfaq-ja/
関連リンクは>>2-10辺り
足りなかったら適当に付け足してね
前スレ
ネットワークプログラミング相談室 Port23
http://pc12.2ch.net/test/read.cgi/tech/1230466044/
関連スレ
ネットワークプログラミング雑談
http://pc12.2ch.net/test/read.cgi/tech/1235800707/
Java ネットワークプログラミング 【教えて!】
http://pc11.2ch.net/test/read.cgi/tech/1086238859/
0232デフォルトの名無しさん
2009/08/02(日) 23:16:01FIN_WAITって鯖側のソケットをclose()しても残ったままになるの？
0234デフォルトの名無しさん
2009/08/02(日) 23:35:32世の中には一方通行通信で良い場合もあるし、一方通行
で構わないタイミング（たとえば、片方は言いたいこと
を全部言い終わったとか）もある。shutdown() で片方
閉じるってのは元々そういう用途だよ。
0235デフォルトの名無しさん
2009/08/02(日) 23:39:05RFC見ましたがソケット関数とtcp状態遷移の関係がわからない。。
首吊って人生やりなおしてきます。orz
0236デフォルトの名無しさん
2009/08/03(月) 00:15:250237デフォルトの名無しさん
2009/08/03(月) 00:25:55よく見掛ける状態遷移図は参考程度にしといた方がいいっ
てスティーブンスも言ってたんだけど。
http://pfsense.org/~cmb/diagrams/tcpStateDiagram1.gif
たとえば↑で斜体になってるのがアプリが呼び出すメソッ
ドと思えばいい。んでもって矢印が状態遷移だけど、
A/B というのは「A が発生したら B を実施して遷移す
る」の意味。「Close/FIN」はアプリが close() したら
FIN を送出して状態遷移。
そして TCP/IP は双方が established 状態になったら
サーバ／クライアントなんていう区別は無くなるんだよ
（そもそも、双方同時に Active open してもコネクショ
ンが張れるように設計されてる）。
ESTABLISHED から下に遷移している左側がアプリによる
close() の遷移で、右側がその応答である FIN を受け
取ったときの遷移。
双方同時に close() したらどうなるかとか考えてみる
といいよ。
0238デフォルトの名無しさん
2009/08/03(月) 00:30:39CLOSE_WAIT ってのは「FIN は来たからアプリの
close() 待ちだな」っていう状態で、この時まだ送信で
きる状態。
FIN_WAIT ってのは「アプリは close() したから FIN
待ちだな」っていう状態で、この時まだ受信出来る状態。
0239222
2009/08/03(月) 00:43:00文書 "RFC 739" 内の図 "Figure 6. TCP Connection State Diagram" は
参照されていると思います。(もし見ていなければ開いてください)
この図の中央に状態 [ESTAB(コネクション確立中)] があります。
この状態でソケットから事象 "CLOSE" を受け付けると、
(TCPスタックは)IPスタック(=クライアント)へ事象 "snd FIN(FINパケットの送信)" を要求し、
(図の左下側にある)状態 [FIN WAIT-1(コネクション解放待ち(1)] へ遷移します。
ここでソケットからの事象 "CLOSE" は、実際にはshutdownかもしれませんし、
(>>216で「closeをいきなり呼んでも暗黙的にこの処理は行なわれる」とあるように)
いきなりのcloseかもしれないし、あるいは(プロセスのexitに伴う)カーネル内部の
close操作かもしれません。そこは実装に依存するのでRFCでは抽象的に記述されています。
で、状態 [FIN WAIT-1(コネクション解放待ち(1)] においては、IPスタック(=クライアント)から
事象 "rcv ACK of FIN(FINに対するACKパケットを受信)"、
あるいは事象 "rcv FIN(FINパケット受信)" を受け付けない限り、
(永遠に)次の状態へは進めない(遷移できない)ことが確認できるのではないかと思います。
これが「(質問>>232にある)鯖側のソケットをclose()しても残ったまま」になる状況(の一例)です。
眠いんで、今晩はこれで落ちます。
0240デフォルトの名無しさん
2009/08/03(月) 00:43:16ｱﾘｶﾞﾄﾝ
でも、その図の何処にもshutdown()が出ていない (´；ω；`)
あの世へ逝ってスティーブンス先生に教えてもらいます。 orz
0241デフォルトの名無しさん
2009/08/03(月) 00:51:21＞(永遠に)次の状態へは進めない(遷移できない)ことが確認できるのではないかと思います
タイムアウトは実装しているだろうから永遠にって事はないでしょ。
１０分くらい放置プレイされるらしいけど。
0242デフォルトの名無しさん
2009/08/03(月) 01:02:45その図でもshutdownの各パラメータとの対応とrecv()がゼロを返す
タイミングとかはわからんな。ある程度は想像付くけどね。
でも、そんな遷移図わからなくてもTCP/IPプログラムの作れて
しまうソッケットって素敵。
0243デフォルトの名無しさん
2009/08/03(月) 01:23:59ちの二つのデータの流れがあって、そのどちらも
「SYN, データ列、FIN」
の順序になってる。SYN の前や FIN の後にデータは存
在しない。
SHUT_WR は「もう書くことありません」だから、FIN の
送出だよ（で、FIN_WAIT）。
SHUT_RD は「もう読みたくありません」だけど、あっち
には関係無い話でせいぜいこっち側が受信バッファを解
放する位の事しか出来ない（もちろん、アプリ側にもデー
タは来なくなる）。
TCP だとこんな感じだけど、別プロトコルだとまた違っ
た動作が割り振られてる場合もあるよ。
0244デフォルトの名無しさん
2009/08/03(月) 01:35:26> タイムアウトは実装しているだろうから永遠にって事はないでしょ。
> １０分くらい放置プレイされるらしいけど。
現実的な問題からそういう実装はあるかもしれないけど、
TCP/IP の規格にそんな話は出てこないよ。
TCP/IP はあくまで信頼性のあるコネクションを提供す
るのが目的だから、たとえば ESTABLISHED 状態でたま
たま双方が最後に送出したデータの ACK を受け取った
まま三日間無通信だったとしても「突然切っていい」な
んて話はないよ（突然切った瞬間にあっちが何か喋るか
もしれない）。
0245デフォルトの名無しさん
2009/08/03(月) 01:57:550246デフォルトの名無しさん
2009/08/03(月) 07:05:39>>208
0247デフォルトの名無しさん
2009/08/03(月) 07:07:17ESTABLISHED で勝手にタイムアウト切断するのは鬼畜だけど
FIN_WAITでのタイムアウトは良いんじゃね？
どうせ一時的な状態だし。
0248デフォルトの名無しさん
2009/08/03(月) 08:16:04まず、SHUT_WR の状態では切断出来ないよね。向うから
のデータはまだ到着する可能性があるし、アプリだって
read() するかもしれない。
次に SHUT_RDWR の場合だけど、これも切断できない。
たとえば FIN_WAIT の変わりに TIME_WAIT 状態に入っ
たとすると、向うからのデータは破棄されるから向うは
ずっと再送処理を行う事になる。
FIN_WAIT の変わりに CLOSED 状態に入ったとすると、
向うからのデータに対して RST が送出されるからコネ
クションが切断されてしまう（正常系と動きが異なって
しまう）。それに本来入るべき TIME_WAIT に入らない
というのは、TIME_WAIT によって慎重に取り除かれてい
た「シーケンス番号重複問題」が顔を出すことにもなる
よ。
ひょっとしたらもう少し新しい RFC では話が違うのか
もしれないけど、俺が実装した頃の話の理解ではこんな
感じ。
0249デフォルトの名無しさん
2009/08/03(月) 08:38:50送ったんだから、その FIN に対する ACK が来るまで
FIN を再送するんだよ。でないと向うに「全部受け取っ
たよ」っていう通知が届いた事が確認出来ないから。
そして（またもや FIN が到着せずに）FIN_WAIT_2 に入っ
たって事は向うがこっちからの ACK を待ってる可能性
があるから、やっぱり向うからの最終データに対する
ACK を再送することになるよね。
0250デフォルトの名無しさん
2009/08/03(月) 08:56:14> でないと向うに「全部受け取ったよ」っていう通知が
> 届いた事が確認出来ない
あー、これ逆だ。「全部送り終わったよ」の通知を向う
が受けた事の確認だね。
0251デフォルトの名無しさん
2009/08/03(月) 10:27:36まあhost_denyされても文句は言えないな。
0252デフォルトの名無しさん
2009/08/03(月) 10:31:54れば無問題。
0253デフォルトの名無しさん
2009/08/03(月) 10:33:36送信端 close() 状態だね。
0254デフォルトの名無しさん
2009/08/03(月) 17:14:31シーケンス番号で区別？
0255デフォルトの名無しさん
2009/08/03(月) 18:24:04むう・・
0256デフォルトの名無しさん
2009/08/03(月) 19:12:48接続ごとにずらすから、しても問題ないのかな
0257デフォルトの名無しさん
2009/08/03(月) 19:14:58頭いいな
0258デフォルトの名無しさん
2009/08/03(月) 22:43:36SHUT_WRしたらrecv()でのゼロを待つんじゃないのか？
そのrecv()のデータは闇に葬られるが。
0259デフォルトの名無しさん
2009/08/03(月) 23:01:59IAC+2バイトと0(nop)は応答する気がなかったら
無視しちゃっても問題ないですよね？
一応teratermから使えてるみたいなのでいいや。
RFCのtelnetオプション追うの疲れた。
0260デフォルトの名無しさん
2009/08/03(月) 23:14:36>>255
巷ではよくセッションの区別は
「ローカルアドレス+ローカルポート+リモートアドレス+リモートポート」
だと言われてますが、スティーブンス本をよ〜く読むと
これに加えて「ローカル NIC」っていうのが付きます。
たとえば NIC が二枚挿さってるモバイル PC で、PPP
で割り当ててもらったローカルアドレスが（運悪く）両
方とも同じだった、といった状態が考えられるからです。
0261デフォルトの名無しさん
2009/08/03(月) 23:20:39手前側で SHUT_WR すると向こう側に FIN が送られます
が、向うからこちらへのデータ送信に影響は無いですよ。
TCP より上のレイヤで「FIN が来たらコネクションクロー
ズ」という約束ごとでも無い限りは。
0262デフォルトの名無しさん
2009/08/04(火) 08:05:170263デフォルトの名無しさん
2009/08/04(火) 17:16:31これ要らない子じゃね？
0264デフォルトの名無しさん
2009/08/04(火) 21:26:390265デフォルトの名無しさん
2009/08/05(水) 21:36:260266デフォルトの名無しさん
2009/08/06(木) 12:14:240267デフォルトの名無しさん
2009/08/06(木) 12:31:17ttp://www.iana.org/assignments/ipv4-address-space/
0268デフォルトの名無しさん
2009/08/06(木) 12:39:000269デフォルトの名無しさん
2009/08/06(木) 12:59:500270デフォルトの名無しさん
2009/08/06(木) 15:02:36発生条件が想像できないんだけど
0271デフォルトの名無しさん
2009/08/06(木) 15:54:31実装にもよるんだろうけど, 書き込み方向が shutdown された
socket に書けば SIGPIPE になるよ.
0272デフォルトの名無しさん
2009/08/06(木) 19:14:01UDPでそれって難しくね？
実装読んだわけじゃないから想像だけど。
0273デフォルトの名無しさん
2009/08/06(木) 19:45:43Unix 系の実装だと SIGPIPE はソケットが扱ってるプロトコルの処理に
ディスパッチする前に判定されるので, shutdown すれば起きるよ
shutdown(s, SHUT_WR);
sendto(s, ....);
まぁ, ふつうやらんわな………
0274デフォルトの名無しさん
2009/08/06(木) 20:38:46あ、なーる
0275デフォルトの名無しさん
2009/08/09(日) 16:04:050276デフォルトの名無しさん
2009/08/09(日) 19:14:27Linuxでソケットを使って簡単なプログラムを書いて
ファイル(6KB)転送をしてみたんですが、
サーバーとクライアントのローカルネットワーク内で直接やり取りすると、
途切れることなく到着するのですが、
インターネット経由だと、30%程度の確率で4242バイトで区切られてしまいます。
これって、何が原因なんでしょうか？どうか教えてください。
0277デフォルトの名無しさん
2009/08/09(日) 19:34:39たぶんインターネット経路の途中にあるルータで
IPパケットが分割されたのが原因だと思います。
もしそうであれば、いたって普通の現象です。
対策については、まずは、このスレの>>72の質問から始まった
一連のレスをじっくり読んでみてください。
0278デフォルトの名無しさん
2009/08/09(日) 20:22:110279276
2009/08/09(日) 23:46:12やっぱり途中のルーターなんですね・・・。
しかもレスを読むと、
全パターンの区切り方を想定してバッファやスタックを作るのが対策・・・。
最低どこまでのサイズで区切られるか、試さないといけませんね・・・。
多分1400バイトが安全圏かなぁ・・・。
まぁ、4242バイトに近いパケットを調べたところ、一個だけ該当するものがありまして
どうやら、FDDIのパケット(4500バイト前後)の大きさで区切られているようです。
0280デフォルトの名無しさん
2009/08/09(日) 23:59:58メッセージサイズ決まってる(固定長)のなら、そのサイズ読み込めばいいし、
決まってないのならメッセージヘッダの中に自分のサイズを含めればいい。
0281デフォルトの名無しさん
2009/08/10(月) 00:28:16どうして他の人の言うこと聞かないんだろ。
まともなコードなら、1byte以上全ての可能性に対処すべきなのに。
0282デフォルトの名無しさん
2009/08/10(月) 00:57:42>多分1400バイトが安全圏かなぁ・・・。
>>278がレスしているように、TCPではメッセージ境界は保証されません。
いわゆるUNIXのパイプと同じ概念で、データの最小単位は1byteでしかないんです。
(だからTCPは「バイトストリーム指向」であると呼ばれることがあります。反意語は「レコード指向」)
言い換えると、理論的には最悪の場合1byte単位でソケットにデータが届くことがあり、
そのケースも想定して実装する必要があります。1400byteなんて安全圏はどこにも存在しません。
もし通信プロセスの実装が同期I/O方式であるなら、>>115の方法を使うのが最も楽です。
そうでないなら(非同期I/O方式であるなら)、推測されたように複雑なFIFO制御が求められます。
そんな設計が苦痛に感じられ、なおかつ(>>279が)アプリケーション層のプロトコル定義を
決定できる立場にあるのだとしたら、専用の通信ライブラリの利用を提案します。
(そのような通信ライブラリのことを「ミドルウェア」と呼ぶことがあります。)
(長いので続く)
0283282
2009/08/10(月) 01:10:06たとえば、Linux上でC/C++を使われるのなら、ONC/RPC(旧名でSunRPCとも呼ばれる)をお勧めします。
いわゆるRPC(Remote Procedure Call)と呼ばれるミドルウェアであり、OSI参照モデルであれば
セッション層からプレゼンテーション層までの範囲に相当するサービスを提供しています。
最も単純な実装の場合、XDR(External Data Representation)と呼ばれる言語でユーザ関数を定義した後、
クライアント側アプリケーションではサーバIPアドレスの指定とユーザ定義関数のコールを実装するだけ、
サーバ側アプリケーションではコールされる(C言語の)ユーザ関数定義を実装するだけで、
あとはONC/RPCシステムにおまかせすることができます。(ONC/RPCシステムのセットアップは必要です)
メッセージ境界処理はもちろんのこと、UNIXソケット実装の差異(Linux/xxxBSD/Solaris/MacOSX等)や
CPUアーキテクチャの差異(Intel/PowerPC/ARM/SPARC等)までも吸収してくれます。
また、非同期コールにも当然対応しています。([例] サーバ：selectで実装、クライアント；GTKで実装)
ただし、ONC/RPCの発想に慣れるまでは、最初の壁がきついかもしれません。
詳細については書籍「RPCプログラミング 株式会社アスキー」を参考にしてください。
また、英語ばかりですが、事前にmanでrpcgenコマンド(XDR言語-->C言語自動生成ツール)を
調べてみたり、RPCプロトコルの仕様書(RFC 1831)を読んでおくのもいいかもしれません。
大半のUNIXでは、C言語開発メタパッケージがインストールさえしてあれば、ONC/RPCは即利用可能です。
ONC/RPCは以前に何度か利用しているので、何か質問あればどーぞ。
0284デフォルトの名無しさん
2009/08/10(月) 01:15:36俺が技術責任者なら却下する。
0285282
2009/08/10(月) 01:58:58ONC/RPCなんてUNIXで標準に付属してる「単なる道具」にすぎないよ。何を怖がってるの？
ただで使えるものは使ったほうがイイと思う。モッタイナイ！！
最初の壁を突破できれば、後は楽々で生産性は向上するわバグも減るわ移植性も確保できる。
本人にとっても習得した技術は他のプロジェクトへ移っても活用できるし。(UNIX限定だけどね)
あとONC/RPCをOMG/CORBAやMicrosoft DCOMみたいな分散オブジェクト技術と
ごちゃまぜにして理解していないかい？
それらと比較すると、ONC/RPCなんて非常にシンプルなシステムだよ。
Web Serviceであれば、SOAPとXML-RPCの差であると言い切ってもいいと思う。(分かるかな？)
まあ、(メッセージの送受信じゃなくて)単なるファイル転送くらいならRPCは大げさかも。
ただし、それを判断するのは>>279のプロジェクトの内容しだいだよ。却下は即断すぎる。
0286デフォルトの名無しさん
2009/08/10(月) 02:17:14いや、それを言うなら単にソケット開いて、メッセージ送受信するだけですむのに。
(さらに、ほぼそのままWindowsに持っていっても動くし、他の言語からも使用しやすい)
Web-Serviceで言えばRest風サービスですむのに(なんなら、PHPで動的テキスト返す
くらいのものでもいい)、何でSOAPとかXML-RPCとか持ち出すの？っていうこと。
0287デフォルトの名無しさん
2009/08/10(月) 02:23:50ftp使えば？
生産性とか移植性とかそんなもんすら関係ないし
0288デフォルトの名無しさん
2009/08/10(月) 02:26:040289282
2009/08/10(月) 03:18:52>いや、それを言うなら単にソケット開いて、メッセージ送受信するだけですむのに。
それが通用するのは同期式I/Oの場合だけで、そのケースについては
>>282で「>>115の方法を使うのが最も楽」と書いてあるよ。よく読んでね。
>(さらに、ほぼそのままWindowsに持っていっても動くし、他の言語からも使用しやすい)
まさかCygwinとかPOSIXサービスが前提とか言い出すんじゃないだろうね？
WinSockが名前はソケットでもUNIXソケットとはまるで実装が違うのは知っているはずだし。
何を指して「ほぼそのままWindowsに持っていっても動く」と言っているの？教えてくださいませ。
>Web-Serviceで言えばRest風サービスですむのに(なんなら、PHPで動的テキスト返す
>くらいのものでもいい)、何でSOAPとかXML-RPCとか持ち出すの？っていうこと。
RESTとXML-RPCはXML前提か否かが違うくらいで、複雑さは同レベルだよ。
しかも、もしXMLの技術を持っていて、なおかつメッセージ定義が複雑になっていった場合、
(サービスとREST APIの対応付けを実現しなければいけないという強い制約があるRESTよりも)
メッセージ型が柔軟に(XMLで定義できる)XML-RPCのほうが設計は容易であるというのが常識だし。
SOAPはXML+HTTPベースの分散オブジェクト技術だから言わずもがな。
結論として複雑さの比較は、XML-RPC = REST << SOAP になる。反論あるかい？
信じられないレスなんだけど、本当にREST/XML-RPC/SOAPを使ったことがあるの？
0290282
2009/08/10(月) 03:25:13>ファイル転送したいだけでしょ？
だからファイル転送のレベルかどうかは>>279しだいだと(>>285で)書いたんだが。
レス読んでいるかい？>>279からレスが来ないかぎり、誰にも判断できないはずだよ。
>ftp使えば？
C言語に(バグの枯れた)デファクトなFTPライブラリってあったっけ？自分は知らない。あれば教えて。
あるいは自分でFTPプロトコルをC言語で実装するということ？本末転倒じゃないか。
それともC言語からftpコマンドを起動するっていうことかな？OK、それなら納得する。
でもそれはネットワークプログラミングから外れる(スレ違いな)提案じゃないのかな？
0291282
2009/08/10(月) 03:40:31>C言語に(バグの枯れた)デファクトなFTPライブラリってあったっけ？自分は知らない。あれば教えて。
>あるいは自分でFTPプロトコルをC言語で実装するということ？本末転倒じゃないか。
>それともC言語からftpコマンドを起動するっていうことかな？OK、それなら納得する。
>でもそれはネットワークプログラミングから外れる(スレ違いな)提案じゃないのかな？
Debianくらいのディストリになれば、C言語で書かれたFTPライブラリパッケージはあっても
おかしくない気がする。あと、GNOME前提でよければ、確かGNOME APIの中に
FTP/HTTP(WebDAV)を扱うライブラリ関数はあったはず。だから、この段落は取り消します。
0292デフォルトの名無しさん
2009/08/10(月) 05:49:15>
> それが通用するのは同期式I/Oの場合だけで
非同期でも問題ないけど。
0293デフォルトの名無しさん
2009/08/10(月) 05:53:09linuxでONC/RPCを使う方法教えてくれ。
サンプルコード的なの。
0294デフォルトの名無しさん
2009/08/10(月) 08:50:11インターフェース書くも実運用もの面倒くさい。 >>280でFAだろ。
0295276=279
2009/08/10(月) 11:59:53UNIX・LinuxでC言語チャットサーバーを作ることを想定してます。
ログメッセージ以外のデータの長さは固定長で決まっているので、
ほぼ固定長のデータをやり取りする事になりますね。
ちなみに、クライアントはFlash(AS3.0)です。
Flashの扱いは慣れているのでこちらについては大丈夫です。
今、ONC/RPCについて調べてみてます。
0296デフォルトの名無しさん
2009/08/10(月) 21:47:340297デフォルトの名無しさん
2009/08/11(火) 03:18:130298デフォルトの名無しさん
2009/08/11(火) 04:17:590299デフォルトの名無しさん
2009/08/11(火) 05:38:29一度にやってくるパケット量を制限したいので。
何かのRFCに載ってませんか？
0300デフォルトの名無しさん
2009/08/11(火) 09:22:12mss だけ小さくしても意味ないと思うぞ
受信バッファサイズとか, その他のパラメータも関わってるんだから…
0301デフォルトの名無しさん
2009/08/11(火) 18:54:03これ付け忘れて困るシチュエーションが思いつかない
0302デフォルトの名無しさん
2009/08/11(火) 19:06:21v6使ってないんだったら意味ねぇと思う
つか, document 読め
0303282
2009/08/11(火) 22:24:58>ちなみに、クライアントはFlash(AS3.0)です。
クライアントはFlashですか....。でしたらONC/RPCの提案は取り下げます。
C言語とActionScriptとの(SwingやJNIのような)バインディング方法や
完成したライブラリをプラグインとして配布する方法を考えないといけないですから。
>>293
>linuxでONC/RPCを使う方法教えてくれ。
オンラインであれば筑波大の講義資料(？)の中に簡潔な解説がありました。
http://www.coins.tsukuba.ac.jp/~yas/coins/dsys-1998/1999-01-19/index.html
あと以下の書籍にも第16章で(ONC/RPCの旧名である)SunRPCが解説されています。
この書籍は(>>3でVol.1が紹介されているように)所蔵されている図書館/書店が多いでしょう。
UNIXネットワークプログラミング〈Vol.2〉IPC:プロセス間通信
http://www.amazon.co.jp/exec/obidos/ASIN/4894712571
>>297
>ONC/RPCなんて今時使ってるのか？w
正直な話、使っている人はほとんどいないでしょう。ただ、(>>285で書いたように)
用途や環境がハマれば、今でも有効な「道具」ですから、このスレで紹介してみました。
最後に、GoogleによるONC/RPCの「車輪の再発明」であるProtocol Bufferを紹介します。
http://journal.mycom.co.jp/articles/2008/07/18/protocolbuffer/menu.html
ONC/RPCと比較すると、C++/Java/Pythonバインディングがある点を除けば、特徴は同一です。
新しいモノ好きな方にはお勧めかもしれません。
0304デフォルトの名無しさん
2009/08/11(火) 22:32:220305デフォルトの名無しさん
2009/08/11(火) 22:51:560306デフォルトの名無しさん
2009/08/11(火) 22:58:470307デフォルトの名無しさん
2009/08/11(火) 23:15:39100回くらい読んだよ。読んでもわからん。
実験もしたけど、あってもなくてもIPv6のIPアドレスがあればIPv6の方引けるし
なければIPv4のが引けるし。
とりあえず保険でつけとけ って感じでいいのか？
0308デフォルトの名無しさん
2009/08/11(火) 23:17:53よくわからんのだけど、実装がコンパクトでオーバーヘッドがほとんどないなら
RPC使ってみたい
0309282
2009/08/12(水) 00:54:25>>276の質問に対する結論も(>>303)で出たので、ONC/RPCに関する話題は
これで終わりにします。長々としたスレ汚し、失礼しました>>all
0310デフォルトの名無しさん
2009/08/12(水) 02:02:330311デフォルトの名無しさん
2009/08/12(水) 13:52:01あとは同じIPアドレスとポートの組のパケットを一定期間受け流すだけだから、
実際の実装ではTCBから切り離してTIME-WAITリストみたいなもので管理すれば、
最大同時接続数に影響しないと考えていいでしょうか？
0312デフォルトの名無しさん
2009/08/12(水) 14:02:00それは管理されてるから対象
同時接続数は同時管理数と読みかえれ
0313デフォルトの名無しさん
2009/08/12(水) 14:08:31言い方を変えればTIME-WAIT用の限定的なTCBに切り替えるという感じです。
フル機能のTCB領域に限りがあるので、
TIME-WAITで使ってしまうと厳しいのです。
0314デフォルトの名無しさん
2009/08/12(水) 14:51:04MSL_timeout 1byte
相手IPaddr 4byte
相手Port 2byte
合計7バイト
MSL_timeout==0なら空きとみなす
相手MACはパケット受け取った時に入れ替える
SND.NXTも同様
RCV.NXTはFINがきたら+1して入れ替える
0315デフォルトの名無しさん
2009/08/12(水) 16:57:03>>260 で示したセッションを区別できないといけない。
あちら側のアドレスとポートが同一でも、こちら側のポー
トが違えばコネクションは生成される。
0316デフォルトの名無しさん
2009/08/12(水) 17:00:52RFC1122も読んでおくといいです。
http://www2s.biglobe.ne.jp/~hig/tcpip/HostReq_Comm02.html#HREQCOM_4_2_2_13
> コネクションが能動的にクローズされた場合、TCP は
> 2×MSL (最大セグメント生存時間) の時間だけ
> TIME-WAIT 状態に留まらなければならない (MUST)。
> しかし TCPは、以下の条件下で TIME-WAIT 状態から
> 直接コネクションを再オープンして、リモート TCP
> からの新しい SYN を受け入れてもよい (MAY)。
>
> 1. 前のコネクションの化身で使用された最も大きい
> シーケンス番号よりも大きい初期シーケンス番号を、
> 新しいコネクションに対して割り当てる。
>
> 2. もし SYN が古い重複であることが判明したら
> TIME-WAIT 状態に戻る。
0317デフォルトの名無しさん
2009/08/12(水) 17:15:58RFC1122もさらっとですが読みました
もしTIME-WAITでSYNがきたら放置する方向でやろうと思ってます
(アクティブオープンを、切断した同一ポートで開こうとする状況は
ほとんどありえない感じなので)
0318デフォルトの名無しさん
2009/08/12(水) 17:18:44あー、そうか
ローカルポートの情報も持ってないとだめですね
0319デフォルトの名無しさん
2009/08/12(水) 18:38:40> アクティブオープンを、切断した同一ポートで開こう
> とする状況は ほとんどありえない感じ
確かスティーブンス本（Unix Network Programming の
一番古い奴）に half association 指定のオープンの話
があったと思うんだけど、あれってパッシブだけだった?
0320デフォルトの名無しさん
2009/08/12(水) 19:00:53ウェブ連中はライトウェイトTCPとか呼びそうだがｗｗｗ
0321デフォルトの名無しさん
2009/08/12(水) 19:07:120322デフォルトの名無しさん
2009/08/13(木) 13:15:21中身を見てみると内容が無いようのはてなですね
消したけど
0323デフォルトの名無しさん
2009/08/13(木) 13:40:10いつのまにかその掲示板に入り浸るようになってしまった・・・
0324デフォルトの名無しさん
2009/08/14(金) 09:28:330325デフォルトの名無しさん
2009/08/14(金) 10:13:44中身を見てみると内容が無いようのahoochiebukuroですね
消したけど
0326デフォルトの名無しさん
2009/08/14(金) 16:04:570327デフォルトの名無しさん
2009/08/14(金) 16:53:190328デフォルトの名無しさん
2009/08/15(土) 11:05:400329デフォルトの名無しさん
2009/08/15(土) 11:46:580330デフォルトの名無しさん
2009/08/15(土) 12:05:43上の方にもいたが、TCPでブロードキャストやマルチキャストが無理なんてのは
バカでもわかりそうな事だが。
0331デフォルトの名無しさん
2009/08/15(土) 12:47:53■ このスレッドは過去ログ倉庫に格納されています