ネットワークプログラミング相談室 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/
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:310266デフォルトの名無しさん
2006/01/30(月) 02:10:27そんなことされるくらいなら唐辛子の持込を許可してやるよ。
0267海原雄山
2006/01/30(月) 02:33:000268デフォルトの名無しさん
2006/01/30(月) 15:54:44キャッシュサーバーとしての機能のみを備えたもの
（ウェブコンテンツをキャッシュして、
回線速度とコンテンツの内容からの即時性を元に、
キャッシュされたものをクライアントに返すか、
ウェブサーバーまで最新コンテンツをとりに行くか判断）
をプログラミングしたいと思っているのですが、
参考にすればいいページやソースコードなどあれば教えて下さい。
0269デフォルトの名無しさん
2006/01/30(月) 16:08:48> コンテンツデリバリーサーバーの、
> キャッシュサーバーとしての機能のみを備えたもの
それキャッシュサーバーやん。
http://www.squid-cache.org/Doc/FAQ/FAQ.html
http://www.squid-cache.org/Doc/Prog-Guide/
http://www.linux.or.jp/JF/JFdocs/TransparentProxy.html
http://www.squid-cache.org/related-software.html
0270デフォルトの名無しさん
2006/01/30(月) 16:09:10その本で十分じゃねえか? 分からなかったら本屋行って他の本買いまくれ。
分かるまで右から順番に買って行け。左からでもいいぞ。
0271デフォルトの名無しさん
2006/01/30(月) 18:23:09http://pc.watch.impress.co.jp/docs/2006/0130/kaigai237.htm
サーバで効果あるかもしれないな。
0272268
2006/01/30(月) 18:43:17回答＆リンクありがとうございます。
0273デフォルトの名無しさん
2006/01/31(火) 09:28:10本屋に行くたびに順番が変わってたりして。
0274デフォルトの名無しさん
2006/01/31(火) 13:46:35それを防止したいなら全部大人買いだ。箱で買え。
本棚ごと買え。株式交換で本屋ごと買収だ。
0275デフォルトの名無しさん
2006/02/01(水) 15:18:54コードも一応うまく動いているようで、クライアント側で"hello"と打てばサーバー側がそれを受け取ります。
それぞれどういう役割をしているかなんとなく理解しているつもりです。
で、これを具体的に使った例が見たいんですが
「TCP/IP ソケット プログラミング」で検索しても
具体的な例はどこにも見つかりません。
なんか簡単な飛行機の予約システムとか
本を注文するシステムのような具体例が載っているリンク知りませんか？
"hello"とかサーバーの時間を調べるくらいじゃ全然面白くないんですよねぇ。
どうかお願いします。
0276デフォルトの名無しさん
2006/02/01(水) 15:49:50Visual C# for Win64API
Visual C# for JVM
つまり.NETはいらない。
ﾈｲﾃｨﾌﾞとｼﾞｬｳﾞｧｳﾞｧｰﾁｬﾙﾏｼｰﾝで動くC#が最高。
そういうこと。
0277デフォルトの名無しさん
2006/02/01(水) 16:24:58テンプレにRFC集のリンクがあるからHTTPでもSMTPでも好きなの読め
0278デフォルトの名無しさん
2006/02/01(水) 17:10:12手近で具体的な使用例といえば、
いま>>275がレスを書き込んだ２ちゃんねるとか。
0279デフォルトの名無しさん
2006/02/01(水) 18:58:58サーバ側で accept したら thread を立ち上げるものです。
接続が1つの場合は問題なく動くのですが、同時に多数の接続を試みると、
双方の recv がしばしば期待(固定長サイズ受信)に反して 0 (EOF)を受信してしまいます。
送信側では send は正常に返っているようなのですが、どうも具合が良く分からないのです。
多数同時接続の時のデバッグするときはどうしていますか？
0280デフォルトの名無しさん
2006/02/01(水) 19:07:30send や recv は、戻り値を見てこんな感じで送る必要がありますが、
やっていますか？
int len = data_size;
char* p = data_ptr;
while (len > 0)
int sent = send(socket, p, len);
if (sent <= 0) エラー処理
len -= sent;
data_ptr += sent;
}
0281デフォルトの名無しさん
2006/02/01(水) 19:08:18>data_ptr += sent;
p+= sent の間違い。
要は、たぶん期待したデータサイズだけ送れていないのではないか、と。
0282デフォルトの名無しさん
2006/02/01(水) 19:26:31早速の回答ありがとうございます。
送り側のループ処理ですね！
受信側は recv を MSG_WAITALL で呼んでいたのですが、なるほど確認してみます！
0283280
2006/02/01(水) 22:32:09同時に一斉にアクセスをかけてみると幾つかの現象が生じるみたいです。
１つのホストでサーバ＆クライアントを動かして、ログを元にペアとなったPIDを
順に追ってみると、サーバが存在しないプロセスに対して応答していることが分かりました。
以下は互いに通信した実際のPIDの組み合わせですが、サーバの20605
はいないはずの何かから accept して、意味のないデータを受信しているようなんです。
どの当りが影響しているのでしょう？？
server-client
20603-20600
20604-20601
20605-????? ← クライアントは存在しないプロセス!?
20609-20602
20610-20606
20611-20607
20612-20608
0284280
2006/02/01(水) 23:17:47accept して、pthread_create した直後に、usleep をちょっと挟んだだけで、上記不具合は
全く生じなくなってしまいました(いや、うれしいんですが)。どういうことなんでしょ。。。
if ( (s = accept(sock, 5)) != -1 ){
pthread_create(XXXX);
usleep(5000);
}
みたいな感じです。
0285デフォルトの名無しさん
2006/02/01(水) 23:19:34俺はお前じゃねー通の
0286デフォルトの名無しさん
2006/02/01(水) 23:25:57send側に問題がないのなら、recvの処理に問題があるのでしょう。
MSG_WAITALL を使わずにループにしてみてはどうですか？
移植性も高まるし。
0287デフォルトの名無しさん
2006/02/02(木) 01:20:07問題の部分を引用しないと、なにが悪いか分かるわけないっつの
0288デフォルトの名無しさん
2006/02/05(日) 18:33:42で、質問です
１ TCPソケット使って GET / HTTP/1.1 をHTTP鯖に送る
２ レスポンスが帰ってくる
３ データ部分に0f38とか、ソースに本来ないものが含まれる
さいしょ、chunk分けされたものかなーって思ってたけど、
RFCに載ってないのかよーわからん・・・
具体的なサイトは、このスレをtelnetでgetしてみると得られるかもしれません。
(とりあえずまんま元の質問をコピペ)
0289288
2006/02/05(日) 18:35:27質問は、この0f38とか言う文字列が何を指しているのか、
最終的には回避したいので、回避する方法につながる何かの情報提供をおまちしておりまｩｩｩｩｩｨ
0290デフォルトの名無しさん
2006/02/05(日) 19:23:24文字通りchunkじゃないの?
HTTP/1.1つけてGETしたんならchunk対応はMUSTなので
平気でchunkで送っていいことになってる。
対応できないんなら1.1を名乗っちゃいけない
■ このスレッドは過去ログ倉庫に格納されています