ネットワークプログラミング相談室 Port16
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
2005/12/31(土) 14:07:24Programming 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辺り
足りなかったら適当に付け足してね
前スレ
ネットワークプログラミング相談室 Port15
http://pc8.2ch.net/test/read.cgi/tech/1128088448/
0166デフォルトの名無しさん
2006/01/20(金) 21:49:38> 経路確保やKEEP-ALIVE以外は全てIP転送を使用する
UDPとTCPが並列関係。
IPはUDPとTCPの下位層で、
UDP使った時もTCP使った時も、IPを使っている。
TCP/IPというのは、IP, TCP, UDP, DNS, HTTPなどプロトコル群の総称。
同じ意味の言葉に、インターネット・プロトコル・スーツがある。
0167デフォルトの名無しさん
2006/01/20(金) 22:51:55ん？ backlog を動的に変えたいのか？
まず、何のためにそんなことしたいのか書いたほうがいいと思う。
(backlog の意味を勘違いしてるに一票を投じておくか…。)
>>166
DNS と HTTP まで含むのか？
0168デフォルトの名無しさん
2006/01/20(金) 23:05:05そういう定義です。> TCP/IP
http://www.ipa.go.jp/security/rfc/RFC2828-03TJA.html#TCP/IP
http://www.instantweb.com/D/dictionary/foldoc.cgi?TCP%2FIP
0169デフォルトの名無しさん
2006/01/21(土) 07:03:10DNS -> UDP -> IP
HTTP -> TCP -> IP
ですよね？
どうして UDP/IP とは言わないんだろう・・・orz
0170デフォルトの名無しさん
2006/01/21(土) 07:26:47すみません。TCPのつもりでIPと書いていました。
用語を適切にしようするよう注意します。
0171デフォルトの名無しさん
2006/01/21(土) 07:35:08いや、言うよ?
0172デフォルトの名無しさん
2006/01/21(土) 07:37:25申し訳ありません。マルチポストしてしまいました。
２度とこのような事はしませんのでご勘弁下さい。
0173デフォルトの名無しさん
2006/01/21(土) 07:46:48言わないな。
TCP/IPが>>168の意味だから。
0174デフォルトの名無しさん
2006/01/21(土) 16:29:19だから、言うって。上のリンク見ても別に否定されないじゃん。
0175デフォルトの名無しさん
2006/01/21(土) 18:04:010176デフォルトの名無しさん
2006/01/21(土) 18:10:09まあ、DNSやHTTPをTCPやIPと同列に語るよりは、ずっとまとも。
0177デフォルトの名無しさん
2006/01/21(土) 18:41:49------------------------------
TCP UDP
------------------------------
IP
0178デフォルトの名無しさん
2006/01/21(土) 18:58:46言うよ。
単にTCPと比べて用途が限定されてるから機会がそれほど多くないだけで。
0179デフォルトの名無しさん
2006/01/21(土) 19:01:38「UDPとIP」を「UDP, IP」と書いたり言うことはあっても、UDP/IPは変だ。
0180デフォルトの名無しさん
2006/01/21(土) 19:17:140181デフォルトの名無しさん
2006/01/21(土) 19:20:42TCPについては「TCP/IP」と明記していながら
UDPについては「UDP」としか書かれていない、なんてことは
まともな書籍、資料等なら、まず無い。
0182デフォルトの名無しさん
2006/01/21(土) 19:59:170183デフォルトの名無しさん
2006/01/21(土) 20:46:440184デフォルトの名無しさん
2006/01/21(土) 21:00:310185デフォルトの名無しさん
2006/01/21(土) 22:35:05> 「UDPとIP」を「UDP, IP」と書いたり言うことは
> あっても、UDP/IPは変だ。
お前、UDP/IP って「UDP と IP」の意味だと思ってる
のか？ そりゃそんな意味で UDP/IP なんて書く奴はい
ないよ。
>>184
何を言いたいの？
0186デフォルトの名無しさん
2006/01/21(土) 22:44:570187デフォルトの名無しさん
2006/01/21(土) 22:47:09>TCPについては「TCP/IP」と明記していながら
"TCP/IP" と書いたら、TCP だけでなく UDP 等も含んだプロトコルセットを
意味するのが一般的でしょう。反対に、UDP/IP という表記は多くの人に
とって違和感のある表現であると思われます。
0188デフォルトの名無しさん
2006/01/21(土) 23:03:410189デフォルトの名無しさん
2006/01/21(土) 23:06:27いつものことだよ
0190デフォルトの名無しさん
2006/01/21(土) 23:08:31１．TCP でこの処理を行えないという点がよく分かりません。
「TCP は非対称だから」という事なのですが。接続の方向のことでしょうか？
２．UDPで UDP Hole punching を行った後は TCP で接続できるのでしょうか？
ちなみに、間違っているかも知れませんが 私は UDP Hole punching を以下のよう
に理解しています。
別々のNAT内に Ha, Hb がありルーターをそれぞれ Ra, Rb とする。
インターネット上に Hc がある。
１．Ha, Hb ともに Hc に接続 Hc は Ha, Hb のグローバルアドレスを記録する。
２．Ha は Hc から Hb のグローバルアドレスを取得し接続する。
この時、Rb が conn NAT でなければ越えられないが、Ra には Hb との変換レ
コードが記録される。
この時点で、Hb から Ha に接続できる。
３．同様に Hb が Ha に接続( punching )する。
0191デフォルトの名無しさん
2006/01/21(土) 23:15:17「TCP over IP」の意味で「TCP/IP」という言葉を使う人が、世界に一人も居ないと思ってるの？
それと同様の意図で「UDP/IP」と言うのは間違いだと言いたいわけ？
0192デフォルトの名無しさん
2006/01/21(土) 23:16:42よろしくお願いいたします。
0193デフォルトの名無しさん
2006/01/21(土) 23:30:26｜ UDP ｜ TCP ｜
｜―――――――｜
｜ IP ｜
｜―――――――｜
0194デフォルトの名無しさん
2006/01/21(土) 23:31:050195デフォルトの名無しさん
2006/01/21(土) 23:31:10∧＿∧ ミ ギャハッハッ ズレてる！ズレてる！
o/⌒（. ;´∀｀）つ
と＿）__つノ ☆ バンバン
∧＿∧
o/⌒（゜Д゜ ）つ
と＿）__つノ
0196デフォルトの名無しさん
2006/01/21(土) 23:32:42>それと同様の意図で「UDP/IP」と言うのは間違いだと言いたいわけ？
こっちは世界的に見て少数派だろうなぁ。
UDP が over IP である事を厳格に明示したい場合ってどういう時?
0197デフォルトの名無しさん
2006/01/21(土) 23:34:46｜
⑤
m（・∀・）＜あなたはだんだんどうでもよくなる…
/
⑤ ))
m（・∀・）＜あなたはだんだんどうでもよくなる…
＼
（( ⑤
0198デフォルトの名無しさん
2006/01/21(土) 23:48:51は？
あんた「UDP/IPは間違い」って言ってんだろ？
多数か少数かは関係ないだろ。
0199デフォルトの名無しさん
2006/01/21(土) 23:55:03誰と勘違いしてるのか知らんが、>>197 でも見て落ち着け。
ちなみに俺も、理由無しに UDP/IP なんて書いてる奴がいたら、ちょっと眉をひそめるな。
0200デフォルトの名無しさん
2006/01/22(日) 00:01:18.-、
(,,■)
0201デフォルトの名無しさん
2006/01/22(日) 00:22:161. TCPでも同様の技法は使える。
非対称の接続を行う場合対称構造にはならない。
(ただしTCPには対称に接続確立する方法がある)
2. NATルータは通常TCPとUDPを区別して管理しているので不能。
ちなみに、登録サーバがあるスタイルのものを、
UDP hole punchingと呼ぶ流儀もあるが、
http://en.wikipedia.org/wiki/UDP_hole_punching
portの利用方法のことだけを言う場合も多い。
http://muziyoshiz.jp/20041225.html
私は後者(の前者)をUCP hole punchingと読んでいる。
0202デフォルトの名無しさん
2006/01/22(日) 01:06:44たくさん送出しちゃいました・・別に大丈夫ですよね？
ちなみに私は18歳女子高生(処女)です。
0203デフォルトの名無しさん
2006/01/22(日) 01:11:360204デフォルトの名無しさん
2006/01/22(日) 01:12:19それはUDP/IPのパケットですね?
0205デフォルトの名無しさん
2006/01/22(日) 02:17:22買った参考書では、一対一でのチャットのソフトではTCP/IPを、複数での
チャットソフトではUDP用いていましたが、TCP/IPで同様に複数でチャットを
するには、接続分ソケットを用意するということでしょうか？
それと、WSAAsyncSelectを使いメッセージ等を単一で処理をするのと、
マルチスレッド化してaccept()などを使用するのと、どちらが良いのでしょうか？
どちらとも、ということでしたら、理由などを参考程度にお願いします。
0206デフォルトの名無しさん
2006/01/22(日) 02:20:040207デフォルトの名無しさん
2006/01/22(日) 02:23:35はい、UDP/IPとちがって、TCPは接続指向ですから、
接続後とにその端点であるソケットが必要になります。
0208205
2006/01/22(日) 02:30:180209デフォルトの名無しさん
2006/01/22(日) 02:35:23TCPは基本的にクラサバで、サーバー側がListenしてクライアントがConnectする。
Listenしているポートには、IPアドレス．ポート番号さえ違えば、いくらでも接続できる。（例：Webサーバーのポート80）
0210デフォルトの名無しさん
2006/01/22(日) 03:01:16<src IP, src port, dst IP, dst port>の四つ組なんですもの。
0211デフォルトの名無しさん
2006/01/22(日) 05:09:31どこかのサイトの誰かのローカルアドレスに届くだけだから大丈夫
0212デフォルトの名無しさん
2006/01/22(日) 12:40:51いや、UDPだって同じだろ？
0213デフォルトの名無しさん
2006/01/22(日) 12:49:12UDPには接続はない。常に一方向である。
よって<dst IP, dst port>だけで目的のソケットまで辿り着く。
TCPはそうではない。<src IP, src port, XXX, 80>は何組みもありうる。
これが>>209が理解し、>>212が理解してないこと。
UDPで、<src IP, src port>にパケットを返すケース、
それは上位層(セッション、アプリケーション)の仕様なのである。
# UDP hole punchingは上位層の振る舞いを利用する。
TCPの場合は、TCP層で<src IP, src port>が相手であることがはっきりしている。
0214デフォルトの名無しさん
2006/01/22(日) 13:29:18TCPのsrcaddr:srcpotが信頼できて、UDPのは信頼できないってだけの話か？
それともUDP・TCPのソケットレイヤにおける動作の違いが言いたい？
TCPだって、相手にデータを返すのは上位層の役割。送信と受信で
TCPソケットを分けるような変態設計もできるわけだし。
0215デフォルトの名無しさん
2006/01/22(日) 13:44:27物理的にも DstAddr、DstPort しか持っていないんですか？
0216デフォルトの名無しさん
2006/01/22(日) 13:47:450217デフォルトの名無しさん
2006/01/22(日) 13:54:28UDPパケットにも、ありますよ。
http://www.faqs.org/rfcs/rfc768.html
けどUDP層ではそれは使わないんです。
それがUDPとTCPのサービスの違いになっています。
> それともUDP・TCPのソケットレイヤにおける動作の違いが言いたい？
その動作はサービスの違いを反映しているんです。
OSIの言葉で言うところの、各層のエンティティのアドレスって考え方を理解してください。
>>210はTCPの極めて基本的な常識です。
TCPの接続を実現するためには四つ組を識別子に使わざるを得ないんです。
# <dst IP, dst port>が同じ接続を認めないといけないので。
UDPには接続がないので、そうではありません。
これを理解してない人はTCP/IPの基本を理解してないと言わざるを得ません。
0218デフォルトの名無しさん
2006/01/22(日) 13:57:33SrcAddrはIPヘッダに、SrcPortはUDPヘッダに。
0219デフォルトの名無しさん
2006/01/22(日) 14:15:36加えるにpseudo headerの中にSrcAddr, DstAddrもある。
0220デフォルトの名無しさん
2006/01/22(日) 14:30:18は間違い。UDPでもconnect済みのソケットは、srcを区別して捨てるようになるから。
0221デフォルトの名無しさん
2006/01/22(日) 14:31:18レイヤーが理解できていませんね。
ヒント: ACK パケット
>>219
え゛？
0222デフォルトの名無しさん
2006/01/22(日) 14:37:40ソケットレベルで無意味なACKは考えない。
そのために、パケットではなくデータという言葉を使ったんだから。
0223やっぱり、理解できていなかったか…。
2006/01/22(日) 14:48:12ふーん、そうなんだ。
で、誰がそんな話してるの？
独り言なら、チラシの裏へ…。
0224デフォルトの名無しさん
2006/01/22(日) 15:11:35http://homepage3.nifty.com/toremoro/p2p/firewall.html の下方にあるように UDP hole punching は UDP
でしかできないとなっています。でも以下の方法でやれば TCP でもできるのでは？．．．
１．STUN サーバー（グローバル状態）に接続して、自分の Address．Portを記録してもらう（サーバー用として）。
２．外部からつなぐ場合、STUN サーバーから Address.Portを取得して、UDP で「サーバー用にポートを切
り替えて」というパケットを送る。
３．ポートを切り替える。
４．外部からTCPで接続する。
駄目でしょうか？
0225デフォルトの名無しさん
2006/01/22(日) 15:40:15> ３．ポートを切り替える。
が無理です。
>>224のように登録サーバを使うhole punchingなら簡単です。
双方自分のIPアドレス、ポート番号を登録して、
ローカルソケットには登録したIPアドレス、ポート番号をbindし、
同時に相手にconnectしにいけばいいだけです。
UDPでも全く同じコードで動きます。
0226デフォルトの名無しさん
2006/01/22(日) 16:00:19＞ローカルソケットには登録したIPアドレス、ポート番号をbindし、
ポートを切り替えるといってたのはその事です。やはりできるのですね？
なんでこれをやりたいかと言いますと、単にNATの背後にある PC 同士で通信したいだけなんです。
でも、UDP でやると セッションとかパケットの並べ替えとかを UDP の上に作りこまないといけないと
書いてあり、場合によっては UDP の上で TCP を発明するぐらい作りこむ事になりかねないって事
だったんです。
でも TCP でも やりようによってはできるんですね。やる気でてきました。
ところで、Symmetric NAT のルーターって全体の何割くらいあるものなのですか？
Symmetric NAT は、ポート番号総当りで突破できるでしょうか？
0227デフォルトの名無しさん
2006/01/22(日) 18:20:47・SYNパケットがhole punchingを行うことになるが、
相手がhole punchingする前にルータにSYNが到達した場合、
ルータの振る舞い、ルータの出したICMPを受けた時のプログラムの振る舞い。
一番簡単なのは中継サーバを使う方法。
0228デフォルトの名無しさん
2006/01/22(日) 20:23:32中継サーバーが確実ですね。
0229デフォルトの名無しさん
2006/01/22(日) 20:51:31udpで実際 Punching holeやってるが
コネクション型のＴＣＰでできるの？
0230デフォルトの名無しさん
2006/01/22(日) 21:11:12すみません。あまりネットワーク詳しくない上に、確認する環境がないもので．．．orz
ただ、WEBで調査した結果、できそうだなと．．．
でも、ルータの変換テーブルへの記録され方が ＴＣＰとＵＤＰ で同じだとの前提ですが。（ConnNAT,Destricted何とかNAT,SymmetricNATなど）
方法としては単純で、以下の手順を行います。
１．PC-A から 外部の PC-B にクライアント接続します。PC-B は PC-B からみたリモートアドレスとリモートポートを取得します。
２．PC-A はローカルポートとリモートポートを逆にして、サーバーとして待機します。
３．外部の PC-X は PC-B から PC-A のアドレスを取得して、クライアントとして接続します。
UDP Hole Punching と違うのは、ポートを逆にする手順だけだと思います。 確認できたとしたら、是非教えて下さい。
0231デフォルトの名無しさん
2006/01/22(日) 21:16:480232デフォルトの名無しさん
2006/01/22(日) 21:19:430233デフォルトの名無しさん
2006/01/22(日) 21:24:390234デフォルトの名無しさん
2006/01/22(日) 21:29:42すみません。さっきの手順でつながるのは ConnNAT の場合だけでした。
DistrictedなんとかNAT （２種類） を考えた場合、 UDP Hole Punching と同じ手順が必要だと思います。
（UDP Hole Punching の手順に ポート逆転 を追加）
0236デフォルトの名無しさん
2006/01/22(日) 21:55:07１．PC-A から 外部の PC-O にクライアント接続して待機。PC-O は PC-O からみたリモートアドレスとリモートポートを取得します。
２．PC-B から 外部の PC-O にクライアント接続して待機。PC-O は PC-O からみたリモートアドレスとリモートポートを取得します。
３．PC-A から PC-B に接続する場合、PC-O に要求を出します。
４．相手方のアドレスとポートを取得した両方の PC は切断して相手方にクライアント接続します。
接続は失敗しますが、自分側ルーターの変換テーブルに相手方とのレコードが残ります。（きっと）
５．PC-B はローカルポートとリモートポートを逆にして、サーバーとして待機します。
６．PC-A は PC-B にクライアント接続します。
0237デフォルトの名無しさん
2006/01/22(日) 23:23:41俺の認識だと
■UDPは非コネクション系だからＮＡＴはそのパケットが正規の
ものか認識できない ＩＰアドレスでは
■送信した時のポートを覚えておいて、そのポートできたパケットを受け入れる
■送信したＩＰアドレスも覚えておく
ＴＣＰのコネクションだと相手のＩＰ固定だからルーターも
アドレスで選別できるよね？
0238デフォルトの名無しさん
2006/01/22(日) 23:32:43ついでに
私が作ったのはＴＶ電話だけど
ＵＤＰの欠落、順序違いはたまに発生するけど
頻度から考えてＴＣＰの再発明までこったする必要ないと
思うが？
ＴＶ電話の音声・映像は逆に再要求で遅延がひどいパケットは
捨てたいからＵＤＰが向いてるけど
>>236さんがリアルタイム性の強いものを作るならばUDPの方が
向いてるし、ファイル系の速度よりも信頼性を取るならば
リレーサーバーで十分と思うが
0239デフォルトの名無しさん
2006/01/22(日) 23:47:22＞■送信したＩＰアドレスも覚えておく
Restricted Cone NAT 送信した相手のＩＰアドレスも覚える
Port-Restricted Cone NAT 送信した相手のＩＰアドレスとポート番号まで覚える
この場合は考慮しています。と言いますか、送信先を覚えない Conn NAT の場合
Punching する必要はなく、STUNサーバーからアドレス取得してアクセスできる。
自分はそう理解しています。（ひとりよがり．．．）
0240デフォルトの名無しさん
2006/01/22(日) 23:57:230241デフォルトの名無しさん
2006/01/23(月) 00:03:49あ、TV電話興味あるー！
今作ってるのは簡単な会議システムで、ライブ映像（音声）とファイル共有、ホワイトボード共有などです。
ライブ映像（音声）以外はローカルで完成しているのですが、マウス移動情報が大量に流れるのでUDPが理想的なのですが。
>>238 さんはTV電話はどのような技術を利用されたのですか？
自分は以前 Flash Communication Server で作ったことはあるのですが、クラサバだし、サーバーソフト値上がり（６００万円！）
したので止めました。
今は RTC で作成を始めたところです。
＞リアルタイム性の強いものを作るならばUDPの方が
＞向いてるし、ファイル系の速度よりも信頼性を取るならば
＞リレーサーバーで十分と思うが
また迷いが出て来ました．．．そんな気がしてたのですが。
でも ルーター の変換レコードって ９０秒程度で消えるというような文章を目たもので。
KEEP-ALIVE 用のパケット送ってれば済む話？
よしゃぁ！ＵＤＰを試してみます。
0242デフォルトの名無しさん
2006/01/23(月) 00:07:30( ﾟдﾟ)ﾊｯ！ それだけ ＳＴＵＮサーバー を経由するか？
ちょっと落ち着いてよく考えてみます。
0243デフォルトの名無しさん
2006/01/23(月) 00:10:46形態的にはネットゲームみたいにしたいんです。
ロビーで相手探して接続するというような。
0244デフォルトの名無しさん
2006/01/23(月) 00:15:39http://sumim.no-ip.com:8080/collab/20
0245デフォルトの名無しさん
2006/01/23(月) 00:26:01文書上に両方から書き込みができる、ズーム、移動等が同期で動くというどっかにありそうな。
場合によっては NetMeeting で事足りるじゃないかって言われるかも．．．orz
0246デフォルトの名無しさん
2006/01/23(月) 00:33:260247238
2006/01/23(月) 00:33:56書くことたくさんあるけど・・・・
リモートツールも作ってます
■ルーターには数分に一度データーを流すことにより接続を維持します
■ファイル転送はＴＣＰでサーバー経由で十分です
■マウスはＵＤＰの方がいいです。ＴＣＰでは効率悪すぎます
マシンスペック、回線により送る量の調整が必要となります
単純なホワイトボードだとマウス情報送るべきではないよ
■今はUPnPを期待して逆向き接続にしてます、双方ＵＰｎＰが使用できない
時はリレーサーバー 複数人の場合は一人でもＵＰｎＰが使用できれば
それをサーバーにします
■UPnPはルーターにＸＭＬで直接送ります。それによりＳＰ２は回避できます
■winsockではＵＤＰは相手に一度でもつながらないと以後 ソケットは
使用不可になるのでオプションで機能をＯＦＦにします
Hole Punching時の不到達前提で相手に送るときです
0248238
2006/01/23(月) 00:40:30Hole Punchingは明日が予測できない技術だから
業務では使用しないほうがいいよ
0249デフォルトの名無しさん
2006/01/23(月) 01:07:02貴重なアドバイスありがとうございます。
＞マシンスペック、回線により送る量の調整が必要となります
そこなんですよね。バッファリングというか、ハンドルの遊びみたいな部分というか。
ＵＰｎＰって操作したことないので全くわかりません。ぅｗ
確か、これから使うグローバルアドレス等をＰＧで指定できるんですよね。勉強します。
>248
ですよね。現時点でも Synmetric NAT は越えられない訳だし．．．
http://www.newrong.com/product/natsdk/ とかはどうなんでしょうねぇ？
0250デフォルトの名無しさん
2006/01/23(月) 06:00:20> ■マウスはＵＤＰの方がいいです。ＴＣＰでは効率悪すぎます
TCP_NODELAYやOOBつーもんがあるが
0251247
2006/01/23(月) 09:10:39すみません書き方悪かったです。本質的にはUDP,TCP関係ないです
回線的には書かれているようにTCP_NODELAYで乗り越えれます
レスの内容がリモートですので相手のマシンの処理能力に
影響される部分が多いです。時間情報つけて処理しきれない事に
気づいた時には回線上には大量のマウスデーターが順番待ちしてます
0252250
2006/01/23(月) 10:12:54むしろ捨てた方がいいという状況下で、
TCPはオーバースペックという話なら納得。
0253デフォルトの名無しさん
2006/01/23(月) 11:51:070254デフォルトの名無しさん
2006/01/23(月) 12:46:130255デフォルトの名無しさん
2006/01/23(月) 12:52:50ﾘｱﾙﾀｲﾑを選ぶならjavaしかないすよね(至#;)
0256デフォルトの名無しさん
2006/01/23(月) 13:16:30BREW(Binary Runtime Environment for Wireless) 7
http://pc8.2ch.net/test/read.cgi/tech/1137502541/
CLDC+MIDP+携帯電話用Javaスレッド part 5
http://pc8.2ch.net/test/read.cgi/tech/1132493827/
おまけ:
iモード携帯電話用Java(iアプリ) Part10
http://pc8.2ch.net/test/read.cgi/tech/1131603113/
0257デフォルトの名無しさん
2006/01/23(月) 22:36:09そういう状況だと、TCP_NODELAY は関係ない。
そのために、OOB つーもんがあるんだが。
0258247
2006/01/24(火) 09:08:45単独に>>251だけ見た場合 そうですね誤解を受ける書き方ですね
ここまで掘り下げる話題でもないんだけど・・・・
リモートに関することでスレ違いだったのでハッキリかかなくてすみません
いらぬ誤解を生んだようです。
>>247でＵＤＰの方が良いというのは訂正します。
TCPではできないというような印象を与えたようです
実際 私もＴＣＰを使ってます（ＵＤＰの方が楽ですが）
>>250さんの言われている通りですが
マウスの生データーをTCPを使ってまで送る必要は無いということです
実際キャプチャするとわかりますが もの凄い数の微小データーが発生します
TCPですとデーターは一定の数まで送信されませんが 実際はTCP_NODELAYを指定しなくても
問題ないぐらいにデーター数は多いです。逆にTCP_NODELAYを指定すると
マウスデーター１つにつき１パケットになるので再送等のリスクは高まります
相手のマシンが たとえばwin98の低スペックの場合データーは処理しきれず
たまります。そこで>>257さんの言われるOut of Bandなわけですが
そこまでＴＣＰの機能を駆使してもデーターを間引く事になります
相手の画面のホワイトボードにはカクカクした線がでます。
そのため、クライアント側でマウスのデーターは補間して送る必要があります
■マウスのデーターを生で送るべきではない
■もし送るならばＵＤＰで十分（TCPでもかまわない）
■データーを落としたくなければアルゴリズムを見直す。
（ここから先はこのスレッドと関係ないけど）
0259デフォルトの名無しさん
2006/01/24(火) 13:14:380260デフォルトの名無しさん
2006/01/28(土) 18:45:59カーソル移動しなくてもデータが生成されるようなハードからの生データは
送るべきないだろうけど、座標情報なら送っていのでは？
ＸとかVNCでもそうやってるだろうし
0261デフォルトの名無しさん
2006/01/28(土) 19:16:43Xはraw bandwidth X拡張ってのがあった。それも端折る。
>>258はまじめだねえ。
0262デフォルトの名無しさん
2006/01/29(日) 13:19:410263デフォルトの名無しさん
2006/01/29(日) 14:07:36現在、ある程度のjavaの勉強が終わったので、javaでネットワークの勉強を始めようと思っています。
最終的にはちょっとしたネットを使ったゲームができればいいなと思っています。
そこでいろいろ検索したのですが、ネットワーク初心者向けのサイトが見つからなかったので
「基礎からわかるTCP/IP Javaネットワークプログラミング」って本を買おうかと思っているのですが
他にオススメのとかご存知の方いるでしょうか。サイトとかでも教えていただけるとうれしいです。
0264デフォルトの名無しさん
2006/01/29(日) 15:16:290265デフォルトの名無しさん
2006/01/29(日) 22:53:31■ このスレッドは過去ログ倉庫に格納されています