- 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/
- 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するのはコストがかかるんだよｗｗｗ
処理スレッドの上限を決めなくても、
スレッドプールにすれば済む話ｗ
そもそもスレッドプールって知ってんのかこの人？
- 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 ]
- 自分で自分の日本語の不自由さを責めなくていいんだよｗ
- 38 名前：デフォルトの名無しさん mailto:sage [2009/01/01(木) 21:05:23 ]
- 大抵わかってない奴は意味不明な言い訳をして日本語云々言いたがる
これはその典型です。
俺の見たところ、>>32と>>36、話かみ合ってないなｗ
- 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
もはやそんな話から始めなければならなくなったかｗｗｗ
- 54 名前：デフォルトの名無しさん mailto:sage [2009/01/01(木) 22:33:29 ]
- まあ素人向けですから。
- 55 名前：デフォルトの名無しさん mailto:sage [2009/01/01(木) 22:35:17 ]
- マルチスレッドスレッドｗに行ってくれ
- 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でもスレッドプールあるけど、
いくつか種類がある。
１、最初に上限を決めておく
＞これはスレッドをあらかじめ作っておくので、
ＡＰＩを読んだあとはパフォーマンスはいい。
２、上限を設定しない
＞スレッドが必要になったらその都度作るが、
スレッドの役目が終了してもスレッドは消えずに残る。
次にスレッドが必要になったとき、プールにあればそれを使う。
- 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 ]
- サーバー１台じゃないだろ 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 ]
- いきなりレス数増えてると思ったら新年からファビョってんのかｗ
- 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ポートはモデムの設定等で開いていない限りは、早ければ１分程度で
受信不能になってしまいます。
- 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で受け取るような
ライブラリを開発しています。
映像は、圧縮、非圧縮の２タイプ有るので、
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スレの方がよさげ
- 102 名前：デフォルトの名無しさん mailto:sage [2009/01/09(金) 22:23:40 ]
- ttp://www.nicovideo.jp/watch/sm5774030
このｽﾚの住人的にはｺﾚどうですか？
- 103 名前：デフォルトの名無しさん mailto:sage [2009/01/10(土) 04:06:09 ]
- さあ・・
ハードで作ったほうが面白いのでは
- 104 名前：デフォルトの名無しさん mailto:sage [2009/01/10(土) 07:38:48 ]
- ttp://jp.youtube.com/watch?v=SmHjQMki32E&NR=1
このｽﾚの住人的にはｺﾚどうですか？
- 105 名前：デフォルトの名無しさん mailto:sage [2009/01/10(土) 08:32:38 ]
- さあ・・
隣の芝生は赤かったってことでは
- 106 名前：デフォルトの名無しさん [2009/01/11(日) 20:10:55 ]
- std::istream的なソケットストリームってなぜ作られないんですかね？
- 107 名前：デフォルトの名無しさん mailto:sage [2009/01/11(日) 20:40:47 ]
- 使いにくいからじゃね？selectとかasyncとかしたいし。
そうでない単純なものなら自分でサクッと作れる（たぶん）し。
- 108 名前：デフォルトの名無しさん mailto:sage [2009/01/11(日) 20:51:16 ]
- >>106
非同期な操作ができないとsocketには向かない。
そういうクラスが欲しいならboost::asioとか調べてみるべし
- 109 名前：デフォルトの名無しさん [2009/01/11(日) 20:51:28 ]
- 原理的に不可能ではないってことですか？
- 110 名前：デフォルトの名無しさん [2009/01/11(日) 20:53:38 ]
- >>108
近い将来32コア位が普通になるらしいので、むしろ非同期のほうが
ソケットに向かなくなるのかななどと思いまして。
- 111 名前：デフォルトの名無しさん mailto:sage [2009/01/11(日) 21:01:58 ]
- socketのようにいつデータが受信されるかわからないものを同期で組むのは面倒だぞ。
- 112 名前：デフォルトの名無しさん mailto:sage [2009/01/11(日) 21:06:03 ]
- >>110
１スレッド１コネクションでも問題は無いけどね。ネットワークプログラミングの難しさはエラー処理にある。
- 113 名前：デフォルトの名無しさん mailto:sage [2009/01/11(日) 21:17:33 ]
- >>109
可能だよ。現実にコネクションを標準入出力にリダイレクトするソフトがある。
- 114 名前：デフォルトの名無しさん [2009/01/11(日) 21:25:09 ]
- boost::asioは調べてみたことがあるんですが、あれはパフォーマンスのために
非同期対応にしてるけど結果的にうまくいっていない感じでしたね。
- 115 名前：デフォルトの名無しさん mailto:sage [2009/01/11(日) 21:28:19 ]
- >>114
それってどういうこと？
非同期モデルは採用したが、それに見合うパフォーマンスが出ていないという話なのか
iostreamベースのラッパーとの相性が悪いという話なのか
- 116 名前：デフォルトの名無しさん mailto:sage [2009/01/11(日) 21:29:02 ]
- iostreamはともかく
stdioのFILEとして扱うのはそれなりには使われてるってば。
- 117 名前：デフォルトの名無しさん mailto:sage [2009/01/11(日) 21:29:55 ]
- >>116
それはブロッキングでやってfdopen()して
タイムアウトはalarm()でって古式ゆかしき方法だよな
- 118 名前：デフォルトの名無しさん [2009/01/11(日) 21:50:21 ]
- >>115
重複IOを活かす為の苦心が感じ取れるが、複雑化してしまった感じ。
- 119 名前：デフォルトの名無しさん mailto:sage [2009/01/11(日) 21:51:19 ]
- >>118
ああ、早い話が綺麗じゃないってことか
- 120 名前：デフォルトの名無しさん [2009/01/13(火) 18:39:57 ]
- socketでサーバライブラリ的なものを作ってます。
Accept後にThread作ってそこで受信応答を行うという、
ごく一般的な方法なのですが、
現状では、階層の一番深いところで受信した
データの解釈と応答データの作成が必要になってしまい、
ライブラリとして意味がなくなってしまいます。
ライブラリには送受信だけさせ、
受信データの解釈と応答バッファの作成は
もっと上の階層で行いたいのですが、
一般的にはどういう方法で行うのでしょうか？
- 121 名前：デフォルトの名無しさん mailto:sage [2009/01/13(火) 19:40:06 ]
- 他人に通じる文章書くようにしましょう。
階層の深いところって何の階層だ？
ライブラリとして意味がなくなるのが自明みたいに書いてるが、
他人にはさっぱり
- 122 名前：デフォルトの名無しさん mailto:sage [2009/01/13(火) 19:51:24 ]
- サーバークラスなりが、コールバック動作をするコードになってないってことじゃね。
- 123 名前：デフォルトの名無しさん mailto:sage [2009/01/13(火) 23:35:09 ]
- >>120
こういうのを一般化する時の問題はデータの区切りの判定です。
どこがデータの区切りで、どこまでデータを読んでから上層に渡せばいいかは
プロトコル依存だからです。 パケットのヘッダに長さが埋め込まれている場合、
CR/LFでメッセージの区切りが指定されている場合等、ひどい場合は階層構造の
データを深くパージングしないと切れ目が分からないなどと言う物も。
>>122
が言う様に普通はコールバックを上層が用意し、データの区切りの判断を
これらのコールバックを呼んで判断するという方法です。 区切りの方法によって
どういうコールバックのインターフェースを用意すればいいかは自分で考えましょう。
- 124 名前：デフォルトの名無しさん mailto:sage [2009/01/14(水) 00:32:59 ]
- コールバックって・・・
クラスって書いてんじゃん
|
 |
