- 1 名前:デフォルトの名無しさん mailto:sage [2008/12/28(日) 21:07:24 ]
- 主にソケットに関しての質疑応答スレッドです。
Programming UNIX Socket FAQ (日本語訳) www.kt.rim.or.jp/~ksk/sock-faq/indexj.html Winsock Programmer's FAQ (日本語訳) www.kt.rim.or.jp/~ksk/wskfaq-ja/ 関連リンクは>>2-10辺り 足りなかったら適当に付け足してね 前スレ ネットワークプログラミング相談室 Port22 pc11.2ch.net/test/read.cgi/tech/1222603744/ 関連スレ Java ネットワークプログラミング 【教えて!】 pc11.2ch.net/test/read.cgi/tech/1086238859/
- 2 名前:デフォルトの名無しさん mailto:sage [2008/12/28(日) 21:09:27 ]
- 過去スレ:
Port21 ttp://pc11.2ch.net/test/read.cgi/tech/1204287577/ Port20 ttp://pc11.2ch.net/test/read.cgi/tech/1186418855/ Port19 ttp://pc10.2ch.net/test/read.cgi/tech/1159692799/ Port18 ttp://pc11.2ch.net/test/read.cgi/tech/1171029896/ Port17 ttp://pc8.2ch.net/test/read.cgi/tech/1148944560/ Port16 ttp://pc8.2ch.net/test/read.cgi/tech/1136005644/ Port15 ttp://pc8.2ch.net/test/read.cgi/tech/1128088448/ Port14 ttp://pc8.2ch.net/test/read.cgi/tech/1118469143/ Port13 ttp://pc8.2ch.net/test/read.cgi/tech/1109793931/ Port12 ttp://pc5.2ch.net/test/read.cgi/tech/1102427855/ Port11 ttp://pc5.2ch.net/test/read.cgi/tech/1096187183/ Port10 ttp://pc5.2ch.net/test/read.cgi/tech/1090385857/ Port9 ttp://pc5.2ch.net/test/read.cgi/tech/1080658835/ Port8 ttp://pc5.2ch.net/test/read.cgi/tech/1073560271/ Port7 ttp://pc5.2ch.net/test/read.cgi/tech/1063035045/ ★行方不明 Port6 ttp://pc5.2ch.net/tech/kako/1052/10521/1052106444.html Port5 ttp://pc2.2ch.net/tech/kako/1040/10402/1040220302.html Port4 ttp://pc3.2ch.net/tech/kako/1034/10342/1034236536.html Port3 ttp://pc3.2ch.net/tech/kako/1023/10233/1023359282.html Port2 ttp://pc.2ch.net/tech/kako/1006/10062/1006258198.html Port1 ttp://pc.2ch.net/tech/kako/970/970344582.html
- 3 名前:デフォルトの名無しさん mailto:sage [2008/12/28(日) 21:10:03 ]
- 図書コーナー:
UNIXネットワークプログラミング〈Vol.1〉ネットワークAPI:ソケットとXTI www.amazon.co.jp/exec/obidos/ASIN/4894712059/ そのソースコード www.unpbook.com/src.html 詳解TCP/IP〈Vol.1〉プロトコル www.amazon.co.jp/exec/obidos/ASIN/4894713209/ 詳解TCP/IP〈Vol.2〉実装 www.amazon.co.jp/exec/obidos/ASIN/4894714957/ 詳解TCP/IP〈Vol.3〉トランザクションTCP, HTTP, NNTP, UNIXドメインプロトコル www.amazon.co.jp/exec/obidos/ASIN/4894716674/ TCP/IPによるネットワーク構築 〈Vol.1〉原理・プロトコル・アーキテクチャ www.amazon.co.jp/exec/obidos/ASIN/432012054X/ 〈Vol.3〉クライアント‐サーバプログラミングとアプリケーション www.amazon.co.jp/exec/obidos/ASIN/4320028007/ Linux/POSIXソケットバージョン www.amazon.co.jp/exec/obidos/ASIN/4320120841/ Windowsソケットバージョン www.amazon.co.jp/exec/obidos/ASIN/4320029992/
- 4 名前:デフォルトの名無しさん mailto:sage [2008/12/28(日) 21:10:34 ]
- マスタリングTCP/IP RTP編
www.amazon.co.jp/exec/obidos/ASIN/4274065618/ Linuxソケットプログラミング?ネットワークプログラミングにおける実践技法 www.amazon.co.jp/exec/obidos/ASIN/4894714671/ Webプロトコル詳解?HTTP/1.1、Webキャッシング、トラフィック特性分析 www.amazon.co.jp/exec/obidos/ASIN/4894715414/ WinSock2.0プログラミング www.amazon.co.jp/exec/obidos/ASIN/4797306882/ 猫でもわかるネットワークプログラミング www.amazon.co.jp/exec/obidos/ASIN/4797323604/ IPv6ネットワークプログラミング www.amazon.co.jp/exec/obidos/ASIN/4756142362/ Visual Basicではじめるネットワークプログラミング超入門 www.amazon.co.jp/exec/obidos/ASIN/4839917523/
- 5 名前:デフォルトの名無しさん mailto:sage [2008/12/28(日) 21:12:04 ]
- URL抜粋:
★規格 RFC 日本語版リスト www5d.biglobe.ne.jp/~stssk/rfcjlist.html JPNIC RFC関連リンク集 rfc-jp.nic.ad.jp/link/ RFC Editor www.rfc-editor.org/ HTMLなRFC (セクションを直に示すのに便利) www.freesoft.org/CIE/RFC/ RFC 2616 "Hypertext Transfer Protocol -- HTTP/1.1" 日本語訳 www.studyinghttp.net/cgi-bin/rfc.cgi?2616 IANA Well known port numbers www.iana.org/assignments/port-numbers
- 6 名前:デフォルトの名無しさん mailto:sage [2008/12/28(日) 21:17:04 ]
- ★プログラミング
C10K ヘヴィーロードサーバ www.kegel.com/c10k.html C10K ヘヴィーロードサーバ(日本語訳) www.hyuki.com/yukiwiki/wiki.cgi?TheC10kProblem MSDN msdn.microsoft.com/library/en-us/dnsitehelp/html/tochelp.asp Raw IP Networking FAQ www.whitefang.com/rin/ Java で packet capture netresearch.ics.uci.edu/kfujii/jpcap/doc/ Randomness Recommendations for Security www.faqs.org/rfcs/rfc1750.html BoostSocket www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostSocket The Code Project - Internet & Network programming www.codeproject.com/internet/ ネットワークプログラミングの基礎知識 (問題ありのサイト?) X68000.q-e-d.net/~68user/net/
- 7 名前:デフォルトの名無しさん mailto:sage [2008/12/28(日) 21:20:20 ]
- ★ツール類
ethereal - www.ethereal.com/ Wireshark - www.wireshark.org/ tcpdump - www.tcpdump.org/ Windump - netgroup-serv.polito.it/netgroup/tools.html WinPcap - www.winpcap.org/ pathchar - ftp://ftp.ee.lbl.gov/pathchar/ pchar - www.employees.org/~bmah/Software/pchar/ Packetyzer - www.networkchemistry.com/products/packetyzer/ libevent - www.monkey.org/~provos/libevent/ ★プロトコル TTCP www.sean.de/Solaris/ttcp.html www.kohala.com/start/ttcp.html UDP Hole Punching homepage3.nifty.com/toremoro/p2p/firewall.html ★IP, TCP実装 www.iti.fi/documentation/miniip.html www.sics.se/~adam/uip/ www.codeguru.com/Cpp/I-N/network/tcpip/article.php/c5447/ www.geocities.jp/bruce_teller/security/garakuta.htm
- 8 名前:デフォルトの名無しさん [2008/12/28(日) 21:21:38 ]
- >>2
過去スレ: Port20 pc11.2ch.net/test/read.cgi/tech/1086238859/
- 9 名前:デフォルトの名無しさん mailto:sage [2008/12/28(日) 22:02:40 ]
- gj
- 10 名前:デフォルトの名無しさん [2008/12/28(日) 22:05:15 ]
- 乙
- 11 名前:デフォルトの名無しさん mailto:sage [2008/12/28(日) 22:27:12 ]
- Z
- 12 名前:デフォルトの名無しさん mailto:sage [2008/12/28(日) 23:03:06 ]
- Port22 の977ですが、
closeの戻り値はチェックしてましたが、ちゃんと0が返ってきてました。 libevent内部で何をしてるかはまだ見れていないですが、 とりあえず共有しておきます。
- 13 名前:デフォルトの名無しさん mailto:sage [2008/12/28(日) 23:38:05 ]
- epollやkqueueあたりの仕組みってWindowsじゃどうなってんだろ?
- 14 名前:デフォルトの名無しさん mailto:sage [2008/12/28(日) 23:51:18 ]
- IOCPや重複I/O
WSAEventSelectやWSAAsyncSelectもね
- 15 名前:デフォルトの名無しさん mailto:sage [2008/12/29(月) 00:25:34 ]
- IOCPはともかく、
重複I/Oはepoll/kqueueとは違うでしょ。 aio_*あたりでしょ。
- 16 名前:デフォルトの名無しさん mailto:sage [2008/12/29(月) 04:34:24 ]
- Port23 って telnet か
- 17 名前:デフォルトの名無しさん mailto:sage [2008/12/31(水) 13:27:03 ]
-
- 18 名前: 【大吉】 mailto:sage [2009/01/01(木) 09:39:47 ]
-
- 19 名前:デフォルトの名無しさん mailto:sage [2009/01/01(木) 18:45:20 ]
- マルチスレッドのサーバを作っています。
複数の処理スレッドが入力を受け付け(accept)、処理を実行し、1つの管理スレッドが スレッド数の管理や処理に関する統計処理等を行っています。 (処理数が処理スレッド数を上回った場合は、管理スレッドが処理スレッドを増やすなどを行う) ここで質問なのですが、管理スレッドを定期的に実行させるにはどのような方法がよいでしょうか? スレッドのpriorityも関係しそうですが、管理スレッドのpriorityをあげるのは、 なんかおかしいかなと思ってます。(実際にpriorityが高いのは処理スレッド) また、もっと適した別のスレッドがあればそれを教えて頂ければと思います。
- 20 名前:デフォルトの名無しさん mailto:sage [2009/01/01(木) 18:52:49 ]
- 19です。ちなみに、linux上でpthreadを使っています。
- 21 名前:デフォルトの名無しさん mailto:sage [2009/01/01(木) 19:20:57 ]
- >処理数が処理スレッド数を上回った場合は、管理スレッドが処理スレッドを増やすなどを行う
こういう風にマルチスレッドをやると大抵破綻する。 スレッドプールにして一度に使うスレッドの上限を決めとかないと、 スレッドが無限に作られるようなこともできてしまう。 ここでいう管理スレッドはずーと起動しておくようなものに設計しないとだめだよ。
- 22 名前:デフォルトの名無しさん mailto:sage [2009/01/01(木) 20:05:11 ]
- 大抵破綻しないが、破綻することもある、だろ
- 23 名前:デフォルトの名無しさん mailto:sage [2009/01/01(木) 20:19:51 ]
- 大抵破綻するだろ
過剰にリクエストが来た場合を考えてみるといい
- 24 名前:デフォルトの名無しさん mailto:sage [2009/01/01(木) 20:32:13 ]
- >> 処理数が処理スレッド数を上回った場合は、管理スレッドが
>> 処理スレッドを増やすなどを行う > こういう風にマルチスレッドをやると大抵破綻する。 増やす上限決めときゃ良いだけの話しだし、管理スレッドをずーと 起動しておくかどうかなんて関係ないし。 何を言いたいのかさっぱりわからん。
- 25 名前:デフォルトの名無しさん mailto:sage [2009/01/01(木) 20:39:22 ]
- >>24
素人なの?
- 26 名前:デフォルトの名無しさん mailto:sage [2009/01/01(木) 20:40:35 ]
- >増やす上限決めときゃ良いだけの話しだし
アホすぎる。 いちいちスレッド作っるようなこと考えてんのかしらこの人?
- 27 名前:デフォルトの名無しさん mailto:sage [2009/01/01(木) 20:42:02 ]
- 破綻するかもしれないが、そうじゃないように使う、とかいう設計はやばいな。
- 28 名前:デフォルトの名無しさん mailto:sage [2009/01/01(木) 20:43:54 ]
- >>26
スレッドプールにして〜 というくだりをみて言ってるっぽいので、 アホなんでしょう。
- 29 名前:デフォルトの名無しさん mailto:sage [2009/01/01(木) 20:48:35 ]
- >>19
スレッドはどういう順番で動くか基本的には操作できないので、 セマフォとか駆使してやってみるのがいいんジャマイカ?
- 30 名前:デフォルトの名無しさん mailto:sage [2009/01/01(木) 20:52:37 ]
- >>19
> スレッドのpriorityも関係しそうですが、管理スレッドのpriorityをあげるのは、 > なんかおかしいかなと思ってます。(実際にpriorityが高いのは処理スレッド) なんか勘違いしてるみたいだけど、基本的に管理スレッドの priority はあげるべき。 普通に組めば管理スレッドはたいして CPU 食わないから全体には影響しない。 >>26 > いちいちスレッド作っるようなこと考えてんのかしらこの人? 日本語不自由な人なの? わざわざ引用してあるのに「処理スレッドを増やすなど」の上限と解釈できないのか? て言うか、Apache とかの実装とかも知らんのか...。
- 31 名前:デフォルトの名無しさん mailto:sage [2009/01/01(木) 20:55:34 ]
- 19です。
上限は予め決めておこうと思います。 apacheのpreforkのモデルと同じように、予めpoolしておいた分に達したら、上限までpoolを増やしいくようなイメージです。 (もちろん、activeなやつが減ってきたら、poolを減らしていく) 今は、条件変数を使ってやろうかと思っていますが、 他にもっとよい方法はありますでしょうか?
- 32 名前:デフォルトの名無しさん mailto:sage [2009/01/01(木) 20:56:03 ]
- pthread_createするのはコストがかかるんだよwww
処理スレッドの上限を決めなくても、 スレッドプールにすれば済む話w そもそもスレッドプールって知ってんのかこの人?
- 33 名前:デフォルトの名無しさん mailto:sage [2009/01/01(木) 20:57:59 ]
- >わざわざ引用してあるのに「処理スレッドを増やすなど」の上限と解釈できないのか?
あんたの文面では理解できない。
- 34 名前:デフォルトの名無しさん mailto:sage [2009/01/01(木) 20:59:36 ]
- スレッドプールってふつうは上限を設定するだろ。
なんなんだこの話の流れは?
- 35 名前:デフォルトの名無しさん mailto:sage [2009/01/01(木) 21:01:09 ]
- 言語は何だ?
- 36 名前:デフォルトの名無しさん mailto:sage [2009/01/01(木) 21:02:19 ]
- >>32
だから Apache のドキュメントでも読んでこいよ。 無駄にスレッド作るとリソース食うからああいう構成にしてるんだし。 >>33 すまん、そこまで日本語に不自由しているとは想定できなかったよ。
- 37 名前:デフォルトの名無しさん mailto:sage [2009/01/01(木) 21:04:14 ]
- 自分で自分の日本語の不自由さを責めなくていいんだよw
- 38 名前:デフォルトの名無しさん mailto:sage [2009/01/01(木) 21:05:23 ]
- 大抵わかってない奴は意味不明な言い訳をして日本語云々言いたがる
これはその典型です。 俺の見たところ、>>32と>>36、話かみ合ってないなw
- 39 名前:デフォルトの名無しさん mailto:sage [2009/01/01(木) 21:09:22 ]
- けんかはやめるんだ
- 40 名前:デフォルトの名無しさん mailto:sage [2009/01/01(木) 21:10:26 ]
- 俺もよくわからない。
なぜ 「無駄にスレッド作るとリソース食うからああいう構成にしてるんだし。 」 が>>32への反論になるんだ? どっちも同じこと言ってるだろ。
- 41 名前:デフォルトの名無しさん mailto:sage [2009/01/01(木) 21:12:16 ]
- ムカついて反論したいだけだろ
- 42 名前:デフォルトの名無しさん mailto:sage [2009/01/01(木) 21:20:09 ]
- かみ合わないことに気付かないで日本語指摘してるやついるのか。
世も末だな。
- 43 名前:デフォルトの名無しさん mailto:sage [2009/01/01(木) 21:42:40 ]
- >>19
スレの流れ見ればわかるように >>21 が切れちゃったみたいだから、 もうこのスレに期待しても無駄。 Apache がベストかどうかは別にして、それなりの実績あるしドキュ メントもしっかりしてるからそれをまず読むことを薦める。 その上で再度質問するがよろし。
- 44 名前:デフォルトの名無しさん mailto:sage [2009/01/01(木) 21:57:51 ]
- キレたのは別の人でしょ。この流れをどう見ても。
- 45 名前:デフォルトの名無しさん mailto:sage [2009/01/01(木) 21:59:32 ]
- アパッチ云々ではなくて、マルチスレッドの使い方の話だろこれ・・・
- 46 名前:デフォルトの名無しさん [2009/01/01(木) 22:05:54 ]
- >> 処理数が処理スレッド数を上回った場合は、管理スレッドが
>> 処理スレッドを増やすなどを行う > こういう風にマルチスレッドをやると大抵破綻する。 増やす上限決めときゃ良いだけの話しだし、管理スレッドをずーと 起動しておくかどうかなんて関係ないし。 読み返してみた。 この部分おかしい。 上限決めとけばというが、>>21氏はプールして上限決めろと言ってる。 後半、管理スレッドは起動しっぱなしの方がいいと言っているが、関係無いかどうかは言及していない。 キレたのは>>25に素人と言われた>>24だろ。 どうでもいいんだがマジで。
- 47 名前:デフォルトの名無しさん mailto:sage [2009/01/01(木) 22:08:07 ]
- 本とどうでもいい。新年からやめろおまいら。
- 48 名前:デフォルトの名無しさん mailto:sage [2009/01/01(木) 22:20:18 ]
- 一番の問題は、質問が曖昧なことだ
- 49 名前:デフォルトの名無しさん mailto:sage [2009/01/01(木) 22:21:40 ]
- なんにでもケチつけるんだな、おまえ
- 50 名前:デフォルトの名無しさん mailto:sage [2009/01/01(木) 22:23:24 ]
- >>21=>>46
相変わらず、何を言いたいのかさっぱりわからん。(w >>48 同意。
- 51 名前:デフォルトの名無しさん mailto:sage [2009/01/01(木) 22:26:01 ]
- >>21が何を言っているのかわからないということはないだろう。
日本語不自由ではなくて、君の技術的に問題があるんじゃないか?>>50よ。
- 52 名前:デフォルトの名無しさん mailto:sage [2009/01/01(木) 22:28:00 ]
- スレッドプールっていうのは、新たにスレッドを作らないで、文字通りスレッドをプールしておく
プールするとき、何個スレッドを作っておくかを初期値として登録するのが基本。(そうじゃない仕様もあるが) なので、ここで上限が云々いう話に持ってくこと自体、この話を理解していないとしか言えない。
- 53 名前:デフォルトの名無しさん [2009/01/01(木) 22:30:15 ]
- >>52
もはやそんな話から始めなければならなくなったかwww
- 54 名前:デフォルトの名無しさん mailto:sage [2009/01/01(木) 22:33:29 ]
- まあ素人向けですから。
- 55 名前:デフォルトの名無しさん mailto:sage [2009/01/01(木) 22:35:17 ]
- マルチスレッドスレッドwに行ってくれ
- 56 名前:デフォルトの名無しさん mailto:sage [2009/01/01(木) 22:40:52 ]
- 最初に全部のスレッド作ると効率悪いから
最初いくつか作っておいて、それで足りなくなったらある単位ごとに継ぎ足す、 でも上限に達するとエラー、ってのが基本だろう。
- 57 名前:デフォルトの名無しさん mailto:sage [2009/01/01(木) 22:45:19 ]
- スレッド数が上限に達してもエラーにはならんよ(ってか、エラーにはしない)。
プールに戻ってくるまでwaitするだろ普通。
- 58 名前:デフォルトの名無しさん mailto:sage [2009/01/01(木) 22:45:54 ]
- >>57
そこはあえて突っ込むべきか迷ってたんだがな
- 59 名前:デフォルトの名無しさん mailto:sage [2009/01/01(木) 22:48:02 ]
- JavaのAPIでもスレッドプールあるけど、
いくつか種類がある。 1、最初に上限を決めておく >これはスレッドをあらかじめ作っておくので、 APIを読んだあとはパフォーマンスはいい。 2、上限を設定しない >スレッドが必要になったらその都度作るが、 スレッドの役目が終了してもスレッドは消えずに残る。 次にスレッドが必要になったとき、プールにあればそれを使う。
- 60 名前:デフォルトの名無しさん mailto:sage [2009/01/01(木) 22:49:39 ]
- スレッドプールを使い切ったらエラーなんてありえねぇよ。
わざとそういう仕様にしない限りね。
- 61 名前:デフォルトの名無しさん [2009/01/01(木) 22:54:14 ]
- 話ぶった切って悪いけど、
googleやyahoo等のwebサーバって、どのくらいの数のユーザスレッドもしくはプロセスが上がるんですか? 10万人が一度に接続してきたとき、10万スレッドが作られるんですか?
- 62 名前:デフォルトの名無しさん mailto:sage [2009/01/01(木) 22:55:34 ]
- サーバー1台じゃないだろ JK
- 63 名前:デフォルトの名無しさん mailto:sage [2009/01/01(木) 22:57:21 ]
- 女子高生と聞いてやってきました
- 64 名前:デフォルトの名無しさん mailto:sage [2009/01/01(木) 22:58:09 ]
- 全部のサーバーがマルチスレッド対応で1リクエストごとに1スレッド作るんだったら全部のサーバーの合計スレッド数は10万になるだろうな
- 65 名前:デフォルトの名無しさん mailto:sage [2009/01/01(木) 23:03:07 ]
- >>61
世の中にはサーバ負荷分散を行うアプライアンス装置ってもんがある JK
- 66 名前:デフォルトの名無しさん [2009/01/02(金) 00:14:39 ]
- 接続の数だけスレッドがある状態だと性能が劣化すると思うが、
なぜそんな構成にするのか?
- 67 名前:デフォルトの名無しさん mailto:sage [2009/01/02(金) 02:14:49 ]
- いきなりレス数増えてると思ったら新年からファビョってんのかw
- 68 名前:デフォルトの名無しさん mailto:sage [2009/01/05(月) 14:56:08 ]
- すみません、NAT越えについて質問させてください。
モデムの内側にあるAとBのマシン同士を、モデムの外にあるCというマシンを 介してP2P通信させたいんです。 まず、AのPCがCのPCにUDPアクセスし、AのWAN側のIPとポートを取得。 同様にBのPCがCのPCにUDPアクセスし、BのWAN側のIPとポートを取得。 その後一分以内に(モデムのポートが開いている間に) 取得したIPとポートにAとBそれぞれからお互いにUDPでアクセスさせれば AとBお互いがモデムの内側であったとしてもUDP通信が可能になると 思いますが違いますでしょうか?
- 69 名前:デフォルトの名無しさん mailto:sage [2009/01/05(月) 15:35:17 ]
- >その後一分以内に(モデムのポートが開いている間に)
これが謎だ
- 70 名前:デフォルトの名無しさん mailto:sage [2009/01/05(月) 15:46:46 ]
- もでむ、つか、NAPT?
- 71 名前:68 mailto:sage [2009/01/05(月) 15:57:52 ]
- 「その後一分以内に」はAとC、あるいはBとCが通信したことにより
AB側のマシンで一時的にUDPポートが開きCとのP2P通信が可能になります。 ただUDPポートはモデムの設定等で開いていない限りは、早ければ1分程度で 受信不能になってしまいます。
- 72 名前:デフォルトの名無しさん mailto:sage [2009/01/05(月) 18:47:20 ]
- >>68
あんたの言う「モデム」っていうのは、いわゆるブロードバンドルータの類の NATルータを指してるんでしょ(モデムと言うと違うものになるから、みんな混乱する)。 で、流れとしては >>68 で合っているが、NATの種類等によってうまくいかない 場合もあるから、あとは UDP Hole Punching でぐぐってくれ。
- 73 名前:68 mailto:sage [2009/01/06(火) 03:15:16 ]
- 解答ありがとうございました。
実はuPnPを使うことで解決してしまいました。 モデムというのはNATルータの事を指すんですね、勉強不足でした。 ありがとうございました。
- 74 名前:デフォルトの名無しさん mailto:sage [2009/01/06(火) 07:54:35 ]
- 映像データをWinsockで受け取るような
ライブラリを開発しています。 映像は、圧縮、非圧縮の2タイプ有るので、 TCPで開発しましたが、 複数接続時に、パフォーマンス問題が出ました。 そこで、UDPを使えという話になり、 試しに、サンプルを作って評価すると、 ロスパケットが多すぎるのでは?と感じています。 UDP使え派の言い分では、映像はUDPを使うのが常識ということなのですが、 UDPだと、圧縮された映像データを無事にデコード・再生するためには、 TCPと似た機構をユーザプログラムに内包することになり、 結局、パフォーマンスは改善できないと思います。 実際のところ、映像データの再生はTCPとUDPのどちらを 使うのが正解でしょうか? 私的には、プロトコルうんぬんで解決できないのでは?と感じており、 その裏づけがほしいと考えています。
- 75 名前:デフォルトの名無しさん mailto:sage [2009/01/06(火) 09:29:04 ]
- LAN内なのかVPNなのかインターネット通して送るのかにもよるんじゃね
LAN内なら環境が変化しにくいという意味でUDPであれこれ調整するというのも考えられるけど それ以外だとやりたくないなあ
- 76 名前:デフォルトの名無しさん mailto:sage [2009/01/06(火) 11:23:53 ]
- >>74
たとえば mpeg には他のフレームを参照すること無しに 画面を構築できる I-frame があるから、UDP でパケッ ト落しても次の I-frame から普通に再生できる。 vsr.informatik.tu-chemnitz.de/~jan/MPEG/HTML/mpeg_tech.html
- 77 名前:デフォルトの名無しさん mailto:sage [2009/01/06(火) 11:36:52 ]
- 完全なデータがほしければTCP,データが落ちてもいいならUDP
でいいんじゃないかと
- 78 名前:デフォルトの名無しさん mailto:sage [2009/01/06(火) 11:42:19 ]
- >>73
> モデムというのはNATルータの事を指すんですね、勉強不足でした。 > ありがとうございました。 NATはNetwork Address Translateの頭字語 ルータはRouter モデムはModulator-Demodulatorの略 ものの名前は意味とつなげて覚えなきゃダメ
- 79 名前:デフォルトの名無しさん mailto:sage [2009/01/06(火) 19:35:35 ]
- >>74
> 複数接続時に、パフォーマンス問題が出ました。 > そこで、UDPを使えという話になり、 ここ論理が飛躍しすぎ(というかたぶん大きく間違ってる)。 まずはこっちの根拠をはっきりさせるべきだな。 TCP/UDP の選択基準は >>77 の言う通り、「落ちても困らないのならUDP、困るのならTCP」 「映像はUDPが常識」な理由は、たいていの映像データは >>76の言うように リアルタイム性を優先させるために「落ちても困らない」ように作ってあるから。 あんたの必要な映像データがどんなのか分からんが、もし「落ちたら困る」ものなら、 > TCPと似た機構をユーザプログラムに内包することになり、 > 結局、パフォーマンスは改善できないと思います。 これは全く正しい。 そのUDP派が上記の理由を踏まえずに言ってるのだとしたらそいつらの方が悪いので、 あんたはもっと強固に主張して良い。
- 80 名前:デフォルトの名無しさん mailto:sage [2009/01/06(火) 19:48:12 ]
- あ、あと気になったのは
> 試しに、サンプルを作って評価すると、 > ロスパケットが多すぎるのでは?と感じています。 これはOKなの? 普通のLAN内の実験環境くらいならそうそう落ちないでしょ。 何か別の問題でパケットロスが多発してるってことはない? だとしたらパフォーマンスが出ない原因はTCPを使ったことそのものではなくて パケットロスによる再送の多発のためってこともあるかもしれんし。
- 81 名前:デフォルトの名無しさん [2009/01/07(水) 16:52:49 ]
- www13.plala.or.jp/kmaeda/winc/dosjyan.htm
このサイトでは、 main関数でwinsock2の初期化後ソケットの作成を試みて、 返り値がINVALID_SOCKETの場合returnで終了していますが、 その場合WSACleanupを処理しないことになりますがこれでいいのでしょうか? // ソケットの作成 sock0= socket(AF_INET,SOCK_STREAM,0); if (sock0 == INVALID_SOCKET){ printf("socket : %d\n", WSAGetLastError()); getch(); return -1; }
- 82 名前:デフォルトの名無しさん mailto:sage [2009/01/07(水) 17:39:41 ]
- >>81
WSACleanup()を呼ばなければならない。 main()で「return -1」とか、センスの悪そうなプログラムだね。
- 83 名前:デフォルトの名無しさん mailto:sage [2009/01/07(水) 17:55:43 ]
- 呼ばなくてもOSがよろしくやってくれて問題起きることはなさそうだけどな。
malloc論争みたいなもんか。
- 84 名前:81 mailto:sage [2009/01/07(水) 18:12:54 ]
- >>82-83
なるほど、ありがとうございます。 mallocについても調べてみます。
- 85 名前:デフォルトの名無しさん mailto:sage [2009/01/07(水) 18:16:57 ]
- MSDN的にはWSACleanup()は「must call」だそうだが、いまどきの
Windowsならたぶん実害はないっぽ。
- 86 名前:デフォルトの名無しさん mailto:sage [2009/01/07(水) 19:06:17 ]
- >>81
WSACleanup() はプログラム終了時に一度だけ呼べば良 いので(というか処理を継続するなら呼んではいけない ので)、ソケット作成失敗とかそういう細々したエラー では呼ばない方が良いと思う。 俺はアプリケーションデストラクタで呼ぶようにしてる。
- 87 名前:デフォルトの名無しさん mailto:sage [2009/01/07(水) 19:11:20 ]
- >>86
もとのコードを良く読みましょう。 main()からreturnしているのです。
- 88 名前:デフォルトの名無しさん mailto:sage [2009/01/07(水) 19:29:36 ]
- atexit
- 89 名前:デフォルトの名無しさん mailto:sage [2009/01/07(水) 19:58:55 ]
- どうせOSが開放するんだからWSACleanupは呼ばなくていいのでは?
なんかまずい事あるかな。
- 90 名前:デフォルトの名無しさん mailto:sage [2009/01/07(水) 20:04:03 ]
- 呼ぶ必要はないと書かれてないなら呼んだ方がいいだろ
- 91 名前:デフォルトの名無しさん mailto:sage [2009/01/07(水) 22:26:14 ]
- >>86
> WSACleanup() はプログラム終了時に一度だけ呼べば良 > い 嘘書いてた(嘘って事でもないけど)。複数回 WSAStartup() を呼んだ場合は、同じ回数 WSACleanup() を呼ぶ必要があるみたいだ(普通そんなことしないと思 うけどね)。 それからプログラムが通信処理継続中に WSACleanup() がエラーを返すことがあるって書いてあるんだけど、こ れは自前でソケットを管理して終了時に shutdown() し て回った方がいいと思う。
- 92 名前:デフォルトの名無しさん mailto:sage [2009/01/07(水) 23:27:17 ]
- まあ現実的にはその辺の作法はWin16時代に必要とされていただけで
Win32だと、OSや他のプロセスに影響が出ることはまずないでしょ。 でも、malloc後のfreeは「しなければいけない」とは書いてないが WSACleanupは「(Startupと同じ回数)しなければいけない」と書いてあるわけで それに従わないのはナンセンスとしか言いようが無いわな。 >91 >普通そんなことしない ライブラリの開発者が自身で呼ぶというのはあるよ。 ドキュメントに「このライブラリを使う前に必ずWSAStartupを呼べ」 と書いておくより良い、という判断で。
- 93 名前:デフォルトの名無しさん mailto:sage [2009/01/08(木) 15:12:07 ]
- プロセス終了時に一回呼び出すだけで良いんだから、
ぐだぐだ言わずに書いとけや、とも思うしね。それで困ることなんてないでしょ。 malloc/free は一プロセス内で何百・何千回も使われることも珍しくないし、 する必要がないものも全部freeしろ、ってのは確かにナンセンスな場合もあるわけなので、 malloc/freeと同一の議論はできないと思う。
- 94 名前:デフォルトの名無しさん mailto:sage [2009/01/08(木) 17:48:29 ]
- mallocの場合は自分でfreeするよりOSがごっそり切り離すほうが効率いいんじゃないの?と信じてあえて書かない
- 95 名前:デフォルトの名無しさん mailto:sage [2009/01/08(木) 17:58:50 ]
- 終了前freeはまあモダンな仮想メモリ実装したOSじゃ意味ねーな
どうせプロセスが終了したらページごと剥がされるだけなのに ヒープをちまちま弄くって、そのためにページフォルトを わざわざひき起こしたりするのは馬鹿げている まあ、C++のような言語では、好む、好まざるに関わらず デストラクタによって無駄な後片付けが走ってしまうだろうがな
- 96 名前:デフォルトの名無しさん mailto:sage [2009/01/08(木) 18:36:36 ]
- 終了時のfreeのせいでアプリのパフォーマンスに問題が出るケースなんてあり得ないので
全部freeする行儀の良いスタイルを身につけておくのが無難だと思うがなあ # C++ではちゃんとdeleteしないとデストラクタが走らないので問題になるかもしれないし 本当にちゃんと解放処理をしっかり書ける上で 意図的にfreeをサボってるならまあ別にいいけれども
- 97 名前:96 mailto:sage [2009/01/08(木) 18:37:10 ]
- スレタイをよく見たらスレ違い気味だったね、すまん
- 98 名前:デフォルトの名無しさん mailto:sage [2009/01/08(木) 23:45:10 ]
- >Winsock Programmer's FAQ (日本語訳)
>www.kt.rim.or.jp/~ksk/wskfaq-ja/ ここを読んでWinsockについて勉強しているのですが Winsock における オーバーラップI/Oとは、どうゆう概念(仕組み?)でしょうか? セッション毎にスレッドを作らなくても、数千〜数万のコネクションを効率的に 処理できると説明にあるのですが、どうゆう仕組みでそれが実現されているのか いまいちイメージができないです・・・
- 99 名前:デフォルトの名無しさん mailto:sage [2009/01/09(金) 01:59:17 ]
- >>98
自己解決しました。(Winsock IOCPでGoogle検索したら 欲しい情報がいっぱい見つかりました)
- 100 名前:デフォルトの名無しさん [2009/01/09(金) 09:54:07 ]
- boost::asioってここのスレ的にどうなの?全く話題に出ないが。
boostスレはともかくとして
- 101 名前:デフォルトの名無しさん mailto:sage [2009/01/09(金) 19:19:07 ]
- boostスレの方がよさげ
|

|