ネットワークプログラミング相談室 Port23

ネットワークプログラ ..

2:デフォルトの名無しさん
08/12/28 21:09:27
過去スレ：
Port21 ｽﾚﾘﾝｸ(tech板)
Port20 ｽﾚﾘﾝｸ(tech板)
Port19 ｽﾚﾘﾝｸ(tech板)
Port18 ｽﾚﾘﾝｸ(tech板)
Port17 ｽﾚﾘﾝｸ(tech板)
Port16 ｽﾚﾘﾝｸ(tech板)
Port15 ｽﾚﾘﾝｸ(tech板)
Port14 ｽﾚﾘﾝｸ(tech板)
Port13 ｽﾚﾘﾝｸ(tech板)
Port12 ｽﾚﾘﾝｸ(tech板)
Port11 ｽﾚﾘﾝｸ(tech板)
Port10 ｽﾚﾘﾝｸ(tech板)
Port9 ｽﾚﾘﾝｸ(tech板)
Port8 ｽﾚﾘﾝｸ(tech板)
Port7 ｽﾚﾘﾝｸ(tech板) ★行方不明
Port6 URLﾘﾝｸ(pc5.2ch.net)
Port5 URLﾘﾝｸ(pc2.2ch.net)
Port4 URLﾘﾝｸ(pc3.2ch.net)
Port3 URLﾘﾝｸ(pc3.2ch.net)
Port2 URLﾘﾝｸ(pc.2ch.net)
Port1 URLﾘﾝｸ(pc.2ch.net)

3:デフォルトの名無しさん
08/12/28 21:10:03
図書コーナー:
UNIXネットワークプログラミング〈Vol.1〉ネットワークAPI:ソケットとXTI
　URLﾘﾝｸ(www.amazon.co.jp)
　そのソースコード
　URLﾘﾝｸ(www.unpbook.com)
詳解TCP/IP〈Vol.1〉プロトコル
　URLﾘﾝｸ(www.amazon.co.jp)
詳解TCP/IP〈Vol.2〉実装
　URLﾘﾝｸ(www.amazon.co.jp)
詳解TCP/IP〈Vol.3〉トランザクションTCP, HTTP, NNTP, UNIXドメインプロトコル
　URLﾘﾝｸ(www.amazon.co.jp)
TCP/IPによるネットワーク構築
　〈Vol.1〉原理・プロトコル・アーキテクチャ
　　URLﾘﾝｸ(www.amazon.co.jp)
　〈Vol.3〉クライアント‐サーバプログラミングとアプリケーション
　　URLﾘﾝｸ(www.amazon.co.jp)
　　Linux/POSIXソケットバージョン
　　URLﾘﾝｸ(www.amazon.co.jp)
　　Windowsソケットバージョン
　　URLﾘﾝｸ(www.amazon.co.jp)

4:デフォルトの名無しさん
08/12/28 21:10:34
マスタリングTCP/IP RTP編
　URLﾘﾝｸ(www.amazon.co.jp)
Linuxソケットプログラミング?ネットワークプログラミングにおける実践技法
　URLﾘﾝｸ(www.amazon.co.jp)
Webプロトコル詳解?HTTP/1.1、Webキャッシング、トラフィック特性分析
　URLﾘﾝｸ(www.amazon.co.jp)
WinSock2.0プログラミング
　URLﾘﾝｸ(www.amazon.co.jp)
猫でもわかるネットワークプログラミング
　URLﾘﾝｸ(www.amazon.co.jp)
IPv6ネットワークプログラミング
　URLﾘﾝｸ(www.amazon.co.jp)
Visual Basicではじめるネットワークプログラミング超入門
　URLﾘﾝｸ(www.amazon.co.jp)

5:デフォルトの名無しさん
08/12/28 21:12:04
URL抜粋:
★規格
RFC 日本語版リスト
　URLﾘﾝｸ(www5d.biglobe.ne.jp)
JPNIC RFC関連リンク集
　URLﾘﾝｸ(rfc-jp.nic.ad.jp)
RFC Editor
　URLﾘﾝｸ(www.rfc-editor.org)
HTMLなRFC (セクションを直に示すのに便利)
　URLﾘﾝｸ(www.freesoft.org)
RFC 2616 "Hypertext Transfer Protocol -- HTTP/1.1" 日本語訳
　URLﾘﾝｸ(www.studyinghttp.net)
IANA Well known port numbers
　URLﾘﾝｸ(www.iana.org)

6:デフォルトの名無しさん
08/12/28 21:17:04
★プログラミング
C10K ヘヴィーロードサーバ
　URLﾘﾝｸ(www.kegel.com)
C10K ヘヴィーロードサーバ(日本語訳)
URLﾘﾝｸ(www.hyuki.com)
MSDN
　URLﾘﾝｸ(msdn.microsoft.com)
Raw IP Networking FAQ
　URLﾘﾝｸ(www.whitefang.com)
Java で packet capture
　URLﾘﾝｸ(netresearch.ics.uci.edu)
Randomness Recommendations for Security
　URLﾘﾝｸ(www.faqs.org)
BoostSocket
　URLﾘﾝｸ(www.crystalclearsoftware.com)
The Code Project - Internet & Network programming
　URLﾘﾝｸ(www.codeproject.com)
ネットワークプログラミングの基礎知識 (問題ありのサイト?)
　URLﾘﾝｸ(X68000.q-e-d.net)

7:デフォルトの名無しさん
08/12/28 21:20:20
★ツール類
ethereal - URLﾘﾝｸ(www.ethereal.com)
Wireshark - URLﾘﾝｸ(www.wireshark.org)
tcpdump - URLﾘﾝｸ(www.tcpdump.org)
Windump - URLﾘﾝｸ(netgroup-serv.polito.it)
WinPcap - URLﾘﾝｸ(www.winpcap.org)
pathchar - fURLﾘﾝｸ(ftp.ee.lbl.gov)
pchar - URLﾘﾝｸ(www.employees.org)
Packetyzer - URLﾘﾝｸ(www.networkchemistry.com)
libevent - URLﾘﾝｸ(www.monkey.org)

★プロトコル
TTCP
　URLﾘﾝｸ(www.sean.de)
　URLﾘﾝｸ(www.kohala.com)
UDP Hole Punching
　URLﾘﾝｸ(homepage3.nifty.com)

★IP, TCP実装
URLﾘﾝｸ(www.iti.fi)
URLﾘﾝｸ(www.sics.se)
URLﾘﾝｸ(www.codeguru.com)
URLﾘﾝｸ(www.geocities.jp)

8:デフォルトの名無しさん
08/12/28 21:21:38
>>2
過去スレ：
Port20 ｽﾚﾘﾝｸ(tech板)

9:デフォルトの名無しさん
08/12/28 22:02:40
gj

10:デフォルトの名無しさん
08/12/28 22:05:15
乙

11:デフォルトの名無しさん
08/12/28 22:27:12
Ｚ

12:デフォルトの名無しさん
08/12/28 23:03:06
Port22 の977ですが、
closeの戻り値はチェックしてましたが、ちゃんと0が返ってきてました。
libevent内部で何をしてるかはまだ見れていないですが、
とりあえず共有しておきます。

13:デフォルトの名無しさん
08/12/28 23:38:05
epollやkqueueあたりの仕組みってWindowsじゃどうなってんだろ?

14:デフォルトの名無しさん
08/12/28 23:51:18
IOCPや重複I/O
WSAEventSelectやWSAAsyncSelectもね

15:デフォルトの名無しさん
08/12/29 00:25:34
IOCPはともかく、
重複I/Oはepoll/kqueueとは違うでしょ。
aio_*あたりでしょ。

16:デフォルトの名無しさん
08/12/29 04:34:24
Port23 って telnet か

17:デフォルトの名無しさん
08/12/31 13:27:03

18: 【大吉】
09/01/01 09:39:47

19:デフォルトの名無しさん
09/01/01 18:45:20
マルチスレッドのサーバを作っています。
複数の処理スレッドが入力を受け付け（accept）、処理を実行し、1つの管理スレッドが
スレッド数の管理や処理に関する統計処理等を行っています。
（処理数が処理スレッド数を上回った場合は、管理スレッドが処理スレッドを増やすなどを行う）
ここで質問なのですが、管理スレッドを定期的に実行させるにはどのような方法がよいでしょうか？

スレッドのpriorityも関係しそうですが、管理スレッドのpriorityをあげるのは、
なんかおかしいかなと思ってます。（実際にpriorityが高いのは処理スレッド）

また、もっと適した別のスレッドがあればそれを教えて頂ければと思います。

20:デフォルトの名無しさん
09/01/01 18:52:49
19です。ちなみに、linux上でpthreadを使っています。

21:デフォルトの名無しさん
09/01/01 19:20:57
>処理数が処理スレッド数を上回った場合は、管理スレッドが処理スレッドを増やすなどを行う

こういう風にマルチスレッドをやると大抵破綻する。
スレッドプールにして一度に使うスレッドの上限を決めとかないと、
スレッドが無限に作られるようなこともできてしまう。

ここでいう管理スレッドはずーと起動しておくようなものに設計しないとだめだよ。

22:デフォルトの名無しさん
09/01/01 20:05:11
大抵破綻しないが、破綻することもある、だろ

23:デフォルトの名無しさん
09/01/01 20:19:51
大抵破綻するだろ

過剰にリクエストが来た場合を考えてみるといい

24:デフォルトの名無しさん
09/01/01 20:32:13
>> 処理数が処理スレッド数を上回った場合は、管理スレッドが
>> 処理スレッドを増やすなどを行う

> こういう風にマルチスレッドをやると大抵破綻する。

増やす上限決めときゃ良いだけの話しだし、管理スレッドをずーと
起動しておくかどうかなんて関係ないし。

何を言いたいのかさっぱりわからん。

25:デフォルトの名無しさん
09/01/01 20:39:22
>>24
素人なの？

26:デフォルトの名無しさん
09/01/01 20:40:35
＞増やす上限決めときゃ良いだけの話しだし

アホすぎる。
いちいちスレッド作っるようなこと考えてんのかしらこの人？

27:デフォルトの名無しさん
09/01/01 20:42:02
破綻するかもしれないが、そうじゃないように使う、とかいう設計はやばいな。

28:デフォルトの名無しさん
09/01/01 20:43:54
>>26
スレッドプールにして～　というくだりをみて言ってるっぽいので、
アホなんでしょう。

29:デフォルトの名無しさん
09/01/01 20:48:35
>>19
スレッドはどういう順番で動くか基本的には操作できないので、
セマフォとか駆使してやってみるのがいいんジャマイカ？

30:デフォルトの名無しさん
09/01/01 20:52:37
>>19
> スレッドのpriorityも関係しそうですが、管理スレッドのpriorityをあげるのは、
> なんかおかしいかなと思ってます。（実際にpriorityが高いのは処理スレッド）

なんか勘違いしてるみたいだけど、基本的に管理スレッドの priority はあげるべき。
普通に組めば管理スレッドはたいして CPU 食わないから全体には影響しない。

>>26
> いちいちスレッド作っるようなこと考えてんのかしらこの人？

日本語不自由な人なの？
わざわざ引用してあるのに「処理スレッドを増やすなど」の上限と解釈できないのか？

て言うか、Apache とかの実装とかも知らんのか...。

31:デフォルトの名無しさん
09/01/01 20:55:34
19です。
上限は予め決めておこうと思います。
apacheのpreforkのモデルと同じように、予めpoolしておいた分に達したら、上限までpoolを増やしいくようなイメージです。
（もちろん、activeなやつが減ってきたら、poolを減らしていく）

今は、条件変数を使ってやろうかと思っていますが、
他にもっとよい方法はありますでしょうか？

32:デフォルトの名無しさん
09/01/01 20:56:03
pthread_createするのはコストがかかるんだよｗｗｗ

処理スレッドの上限を決めなくても、
スレッドプールにすれば済む話ｗ

そもそもスレッドプールって知ってんのかこの人？

33:デフォルトの名無しさん
09/01/01 20:57:59
＞わざわざ引用してあるのに「処理スレッドを増やすなど」の上限と解釈できないのか？

あんたの文面では理解できない。

34:デフォルトの名無しさん
09/01/01 20:59:36
スレッドプールってふつうは上限を設定するだろ。
なんなんだこの話の流れは？

35:デフォルトの名無しさん
09/01/01 21:01:09
言語は何だ？

36:デフォルトの名無しさん
09/01/01 21:02:19
>>32
だから Apache のドキュメントでも読んでこいよ。
無駄にスレッド作るとリソース食うからああいう構成にしてるんだし。

>>33
すまん、そこまで日本語に不自由しているとは想定できなかったよ。

37:デフォルトの名無しさん
09/01/01 21:04:14
自分で自分の日本語の不自由さを責めなくていいんだよｗ

38:デフォルトの名無しさん
09/01/01 21:05:23
大抵わかってない奴は意味不明な言い訳をして日本語云々言いたがる
これはその典型です。

俺の見たところ、>>32と>>36、話かみ合ってないなｗ

39:デフォルトの名無しさん
09/01/01 21:09:22
けんかはやめるんだ

40:デフォルトの名無しさん
09/01/01 21:10:26
俺もよくわからない。

なぜ
「無駄にスレッド作るとリソース食うからああいう構成にしてるんだし。」
が>>32への反論になるんだ？　
どっちも同じこと言ってるだろ。

41:デフォルトの名無しさん
09/01/01 21:12:16
ムカついて反論したいだけだろ

42:デフォルトの名無しさん
09/01/01 21:20:09
かみ合わないことに気付かないで日本語指摘してるやついるのか。
世も末だな。

43:デフォルトの名無しさん
09/01/01 21:42:40
>>19
スレの流れ見ればわかるように >>21 が切れちゃったみたいだから、
もうこのスレに期待しても無駄。
Apache がベストかどうかは別にして、それなりの実績あるしドキュ
メントもしっかりしてるからそれをまず読むことを薦める。

その上で再度質問するがよろし。

44:デフォルトの名無しさん
09/01/01 21:57:51
キレたのは別の人でしょ。この流れをどう見ても。

45:デフォルトの名無しさん
09/01/01 21:59:32
アパッチ云々ではなくて、マルチスレッドの使い方の話だろこれ・・・

46:デフォルトの名無しさん
09/01/01 22:05:54
>> 処理数が処理スレッド数を上回った場合は、管理スレッドが
>> 処理スレッドを増やすなどを行う

> こういう風にマルチスレッドをやると大抵破綻する。

増やす上限決めときゃ良いだけの話しだし、管理スレッドをずーと
起動しておくかどうかなんて関係ないし。

読み返してみた。
この部分おかしい。
上限決めとけばというが、>>21氏はプールして上限決めろと言ってる。
後半、管理スレッドは起動しっぱなしの方がいいと言っているが、関係無いかどうかは言及していない。

キレたのは>>25に素人と言われた>>24だろ。

どうでもいいんだがマジで。

47:デフォルトの名無しさん
09/01/01 22:08:07
本とどうでもいい。新年からやめろおまいら。

48:デフォルトの名無しさん
09/01/01 22:20:18
一番の問題は、質問が曖昧なことだ

49:デフォルトの名無しさん
09/01/01 22:21:40
なんにでもケチつけるんだな、おまえ

50:デフォルトの名無しさん
09/01/01 22:23:24
>>21=>>46
相変わらず、何を言いたいのかさっぱりわからん。(w

>>48
同意。

51:デフォルトの名無しさん
09/01/01 22:26:01
>>21が何を言っているのかわからないということはないだろう。
日本語不自由ではなくて、君の技術的に問題があるんじゃないか？>>50よ。

52:デフォルトの名無しさん
09/01/01 22:28:00
スレッドプールっていうのは、新たにスレッドを作らないで、文字通りスレッドをプールしておく
プールするとき、何個スレッドを作っておくかを初期値として登録するのが基本。（そうじゃない仕様もあるが）
なので、ここで上限が云々いう話に持ってくこと自体、この話を理解していないとしか言えない。

53:デフォルトの名無しさん
09/01/01 22:30:15
>>52
もはやそんな話から始めなければならなくなったかｗｗｗ

54:デフォルトの名無しさん
09/01/01 22:33:29
まあ素人向けですから。

55:デフォルトの名無しさん
09/01/01 22:35:17
マルチスレッドスレッドｗに行ってくれ

56:デフォルトの名無しさん
09/01/01 22:40:52
最初に全部のスレッド作ると効率悪いから
最初いくつか作っておいて、それで足りなくなったらある単位ごとに継ぎ足す、
でも上限に達するとエラー、ってのが基本だろう。

57:デフォルトの名無しさん
09/01/01 22:45:19
スレッド数が上限に達してもエラーにはならんよ（ってか、エラーにはしない）。
プールに戻ってくるまでwaitするだろ普通。

58:デフォルトの名無しさん
09/01/01 22:45:54
>>57
そこはあえて突っ込むべきか迷ってたんだがな

59:デフォルトの名無しさん
09/01/01 22:48:02
JavaのAPIでもスレッドプールあるけど、
いくつか種類がある。

１、最初に上限を決めておく
＞これはスレッドをあらかじめ作っておくので、
ＡＰＩを読んだあとはパフォーマンスはいい。

２、上限を設定しない
＞スレッドが必要になったらその都度作るが、
スレッドの役目が終了してもスレッドは消えずに残る。
次にスレッドが必要になったとき、プールにあればそれを使う。

60:デフォルトの名無しさん
09/01/01 22:49:39
スレッドプールを使い切ったらエラーなんてありえねぇよ。
わざとそういう仕様にしない限りね。

61:デフォルトの名無しさん
09/01/01 22:54:14
話ぶった切って悪いけど、
googleやyahoo等のwebサーバって、どのくらいの数のユーザスレッドもしくはプロセスが上がるんですか？
10万人が一度に接続してきたとき、10万スレッドが作られるんですか？

62:デフォルトの名無しさん
09/01/01 22:55:34
サーバー１台じゃないだろ JK

63:デフォルトの名無しさん
09/01/01 22:57:21
女子高生と聞いてやってきました

64:デフォルトの名無しさん
09/01/01 22:58:09
全部のサーバーがマルチスレッド対応で1リクエストごとに1スレッド作るんだったら全部のサーバーの合計スレッド数は10万になるだろうな

65:デフォルトの名無しさん
09/01/01 23:03:07
>>61
世の中にはサーバ負荷分散を行うアプライアンス装置ってもんがある JK

66:デフォルトの名無しさん
09/01/02 00:14:39
接続の数だけスレッドがある状態だと性能が劣化すると思うが、
なぜそんな構成にするのか？

67:デフォルトの名無しさん
09/01/02 02:14:49
いきなりレス数増えてると思ったら新年からファビョってんのかｗ

68:デフォルトの名無しさん
09/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:デフォルトの名無しさん
09/01/05 15:35:17
＞その後一分以内に（モデムのポートが開いている間に）
これが謎だ

70:デフォルトの名無しさん
09/01/05 15:46:46
もでむ、つか、NAPT?

71:68
09/01/05 15:57:52
「その後一分以内に」はAとC、あるいはBとCが通信したことにより
AB側のマシンで一時的にUDPポートが開きCとのP2P通信が可能になります。
ただUDPポートはモデムの設定等で開いていない限りは、早ければ１分程度で
受信不能になってしまいます。

72:デフォルトの名無しさん
09/01/05 18:47:20
>>68
あんたの言う「モデム」っていうのは、いわゆるブロードバンドルータの類の
NATルータを指してるんでしょ(モデムと言うと違うものになるから、みんな混乱する)。

で、流れとしては >>68 で合っているが、NATの種類等によってうまくいかない
場合もあるから、あとは UDP Hole Punching でぐぐってくれ。

73:68
09/01/06 03:15:16
解答ありがとうございました。
実はuPnPを使うことで解決してしまいました。

モデムというのはNATルータの事を指すんですね、勉強不足でした。
ありがとうございました。

74:デフォルトの名無しさん
09/01/06 07:54:35
映像データをWinsockで受け取るような
ライブラリを開発しています。
映像は、圧縮、非圧縮の２タイプ有るので、
TCPで開発しましたが、
複数接続時に、パフォーマンス問題が出ました。
そこで、UDPを使えという話になり、
試しに、サンプルを作って評価すると、
ロスパケットが多すぎるのでは？と感じています。

UDP使え派の言い分では、映像はUDPを使うのが常識ということなのですが、
UDPだと、圧縮された映像データを無事にデコード・再生するためには、
TCPと似た機構をユーザプログラムに内包することになり、
結局、パフォーマンスは改善できないと思います。
実際のところ、映像データの再生はTCPとUDPのどちらを
使うのが正解でしょうか？

私的には、プロトコルうんぬんで解決できないのでは？と感じており、
その裏づけがほしいと考えています。

75:デフォルトの名無しさん
09/01/06 09:29:04
LAN内なのかVPNなのかインターネット通して送るのかにもよるんじゃね

LAN内なら環境が変化しにくいという意味でUDPであれこれ調整するというのも考えられるけど
それ以外だとやりたくないなあ

76:デフォルトの名無しさん
09/01/06 11:23:53
>>74
たとえば mpeg には他のフレームを参照すること無しに
画面を構築できる I-frame があるから、UDP でパケッ
ト落しても次の I-frame から普通に再生できる。

URLﾘﾝｸ(vsr.informatik.tu-chemnitz.de)

77:デフォルトの名無しさん
09/01/06 11:36:52
完全なデータがほしければTCP,データが落ちてもいいならUDP
でいいんじゃないかと

78:デフォルトの名無しさん
09/01/06 11:42:19
>>73
> モデムというのはNATルータの事を指すんですね、勉強不足でした。
> ありがとうございました。

NATはNetwork Address Translateの頭字語
ルータはRouter
モデムはModulator-Demodulatorの略

ものの名前は意味とつなげて覚えなきゃダメ

79:デフォルトの名無しさん
09/01/06 19:35:35
>>74
> 複数接続時に、パフォーマンス問題が出ました。
> そこで、UDPを使えという話になり、
ここ論理が飛躍しすぎ(というかたぶん大きく間違ってる)。
まずはこっちの根拠をはっきりさせるべきだな。

TCP/UDP の選択基準は >>77 の言う通り、「落ちても困らないのならUDP、困るのならTCP」
「映像はUDPが常識」な理由は、たいていの映像データは >>76の言うように
リアルタイム性を優先させるために「落ちても困らない」ように作ってあるから。

あんたの必要な映像データがどんなのか分からんが、もし「落ちたら困る」ものなら、
> TCPと似た機構をユーザプログラムに内包することになり、
> 結局、パフォーマンスは改善できないと思います。
これは全く正しい。

そのUDP派が上記の理由を踏まえずに言ってるのだとしたらそいつらの方が悪いので、
あんたはもっと強固に主張して良い。

80:デフォルトの名無しさん
09/01/06 19:48:12
あ、あと気になったのは
> 試しに、サンプルを作って評価すると、
> ロスパケットが多すぎるのでは？と感じています。

これはOKなの? 普通のLAN内の実験環境くらいならそうそう落ちないでしょ。
何か別の問題でパケットロスが多発してるってことはない?

だとしたらパフォーマンスが出ない原因はTCPを使ったことそのものではなくて
パケットロスによる再送の多発のためってこともあるかもしれんし。

81:デフォルトの名無しさん
09/01/07 16:52:49
URLﾘﾝｸ(www13.plala.or.jp)

このサイトでは、
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:デフォルトの名無しさん
09/01/07 17:39:41
>>81
WSACleanup()を呼ばなければならない。
main()で「return -1」とか、センスの悪そうなプログラムだね。

83:デフォルトの名無しさん
09/01/07 17:55:43
呼ばなくてもOSがよろしくやってくれて問題起きることはなさそうだけどな。
malloc論争みたいなもんか。

84:81
09/01/07 18:12:54
>>82-83
なるほど、ありがとうございます。
mallocについても調べてみます。

85:デフォルトの名無しさん
09/01/07 18:16:57
MSDN的にはWSACleanup()は「must call」だそうだが、いまどきの
Windowsならたぶん実害はないっぽ。

86:デフォルトの名無しさん
09/01/07 19:06:17
>>81
WSACleanup() はプログラム終了時に一度だけ呼べば良
いので（というか処理を継続するなら呼んではいけない
ので）、ソケット作成失敗とかそういう細々したエラー
では呼ばない方が良いと思う。

俺はアプリケーションデストラクタで呼ぶようにしてる。

87:デフォルトの名無しさん
09/01/07 19:11:20
>>86
もとのコードを良く読みましょう。
main()からreturnしているのです。

88:デフォルトの名無しさん
09/01/07 19:29:36
atexit

89:デフォルトの名無しさん
09/01/07 19:58:55
どうせOSが開放するんだからWSACleanupは呼ばなくていいのでは？
なんかまずい事あるかな。

90:デフォルトの名無しさん
09/01/07 20:04:03
呼ぶ必要はないと書かれてないなら呼んだ方がいいだろ

91:デフォルトの名無しさん
09/01/07 22:26:14
>>86
> WSACleanup() はプログラム終了時に一度だけ呼べば良
> い

嘘書いてた（嘘って事でもないけど）。複数回
WSAStartup() を呼んだ場合は、同じ回数 WSACleanup()
を呼ぶ必要があるみたいだ（普通そんなことしないと思
うけどね）。

それからプログラムが通信処理継続中に WSACleanup()
がエラーを返すことがあるって書いてあるんだけど、こ
れは自前でソケットを管理して終了時に shutdown() し
て回った方がいいと思う。

92:デフォルトの名無しさん
09/01/07 23:27:17
まあ現実的にはその辺の作法はWin16時代に必要とされていただけで
Win32だと、OSや他のプロセスに影響が出ることはまずないでしょ。
でも、malloc後のfreeは「しなければいけない」とは書いてないが
WSACleanupは「(Startupと同じ回数)しなければいけない」と書いてあるわけで
それに従わないのはナンセンスとしか言いようが無いわな。

>91
>普通そんなことしない
ライブラリの開発者が自身で呼ぶというのはあるよ。
ドキュメントに「このライブラリを使う前に必ずWSAStartupを呼べ」
と書いておくより良い、という判断で。

93:デフォルトの名無しさん
09/01/08 15:12:07
プロセス終了時に一回呼び出すだけで良いんだから、
ぐだぐだ言わずに書いとけや、とも思うしね。それで困ることなんてないでしょ。

malloc/free は一プロセス内で何百・何千回も使われることも珍しくないし、
する必要がないものも全部freeしろ、ってのは確かにナンセンスな場合もあるわけなので、
malloc/freeと同一の議論はできないと思う。

94:デフォルトの名無しさん
09/01/08 17:48:29
mallocの場合は自分でfreeするよりOSがごっそり切り離すほうが効率いいんじゃないの？と信じてあえて書かない

95:デフォルトの名無しさん
09/01/08 17:58:50
終了前freeはまあモダンな仮想メモリ実装したOSじゃ意味ねーな

どうせプロセスが終了したらページごと剥がされるだけなのに
ヒープをちまちま弄くって、そのためにページフォルトを
わざわざひき起こしたりするのは馬鹿げている

まあ、C++のような言語では、好む、好まざるに関わらず
デストラクタによって無駄な後片付けが走ってしまうだろうがな

96:デフォルトの名無しさん
09/01/08 18:36:36
終了時のfreeのせいでアプリのパフォーマンスに問題が出るケースなんてあり得ないので
全部freeする行儀の良いスタイルを身につけておくのが無難だと思うがなあ
＃ C++ではちゃんとdeleteしないとデストラクタが走らないので問題になるかもしれないし

本当にちゃんと解放処理をしっかり書ける上で
意図的にfreeをサボってるならまあ別にいいけれども

97:96
09/01/08 18:37:10
スレタイをよく見たらスレ違い気味だったね、すまん

98:デフォルトの名無しさん
09/01/08 23:45:10
>Winsock Programmer's FAQ (日本語訳)
>URLﾘﾝｸ(www.kt.rim.or.jp)

ここを読んでWinsockについて勉強しているのですが Winsock における
オーバーラップI/Oとは、どうゆう概念（仕組み？）でしょうか？

セッション毎にスレッドを作らなくても、数千～数万のコネクションを効率的に
処理できると説明にあるのですが、どうゆう仕組みでそれが実現されているのか
いまいちｲﾒｰｼﾞができないです・・・

99:デフォルトの名無しさん
09/01/09 01:59:17
>>98
自己解決しました。（Winsock IOCPでGoogle検索したら
欲しい情報がいっぱい見つかりました）

100:デフォルトの名無しさん
09/01/09 09:54:07
boost::asioってここのスレ的にどうなの？全く話題に出ないが。
boostスレはともかくとして

101:デフォルトの名無しさん
09/01/09 19:19:07
boostスレの方がよさげ

102:デフォルトの名無しさん
09/01/09 22:23:40
URLﾘﾝｸ(www.nicovideo.jp)
このｽﾚの住人的にはｺﾚどうですか？

103:デフォルトの名無しさん
09/01/10 04:06:09
さあ・・
ハードで作ったほうが面白いのでは

104:デフォルトの名無しさん
09/01/10 07:38:48
URLﾘﾝｸ(jp.youtube.com)
このｽﾚの住人的にはｺﾚどうですか？

105:デフォルトの名無しさん
09/01/10 08:32:38
さあ・・
隣の芝生は赤かったってことでは

106:デフォルトの名無しさん
09/01/11 20:10:55
std::istream的なソケットストリームってなぜ作られないんですかね？

107:デフォルトの名無しさん
09/01/11 20:40:47
使いにくいからじゃね？selectとかasyncとかしたいし。
そうでない単純なものなら自分でサクッと作れる（たぶん）し。

108:デフォルトの名無しさん
09/01/11 20:51:16
>>106
非同期な操作ができないとsocketには向かない。
そういうクラスが欲しいならboost::asioとか調べてみるべし

109:デフォルトの名無しさん
09/01/11 20:51:28
原理的に不可能ではないってことですか？

110:デフォルトの名無しさん
09/01/11 20:53:38
>>108
近い将来32コア位が普通になるらしいので、むしろ非同期のほうが
ソケットに向かなくなるのかななどと思いまして。

111:デフォルトの名無しさん
09/01/11 21:01:58
socketのようにいつデータが受信されるかわからないものを同期で組むのは面倒だぞ。

112:デフォルトの名無しさん
09/01/11 21:06:03
>>110
１スレッド１コネクションでも問題は無いけどね。ネットワークプログラミングの難しさはエラー処理にある。

113:デフォルトの名無しさん
09/01/11 21:17:33
>>109
可能だよ。現実にコネクションを標準入出力にリダイレクトするソフトがある。

114:デフォルトの名無しさん
09/01/11 21:25:09
boost::asioは調べてみたことがあるんですが、あれはパフォーマンスのために
非同期対応にしてるけど結果的にうまくいっていない感じでしたね。

115:デフォルトの名無しさん
09/01/11 21:28:19
>>114
それってどういうこと？
非同期モデルは採用したが、それに見合うパフォーマンスが出ていないという話なのか
iostreamベースのラッパーとの相性が悪いという話なのか

116:デフォルトの名無しさん
09/01/11 21:29:02
iostreamはともかく
stdioのFILEとして扱うのはそれなりには使われてるってば。

117:デフォルトの名無しさん
09/01/11 21:29:55
>>116
それはブロッキングでやってfdopen()して
タイムアウトはalarm()でって古式ゆかしき方法だよな

118:デフォルトの名無しさん
09/01/11 21:50:21
>>115
重複IOを活かす為の苦心が感じ取れるが、複雑化してしまった感じ。

119:デフォルトの名無しさん
09/01/11 21:51:19
>>118
ああ、早い話が綺麗じゃないってことか

120:デフォルトの名無しさん
09/01/13 18:39:57
socketでサーバライブラリ的なものを作ってます。
Accept後にThread作ってそこで受信応答を行うという、
ごく一般的な方法なのですが、
現状では、階層の一番深いところで受信した
データの解釈と応答データの作成が必要になってしまい、
ライブラリとして意味がなくなってしまいます。
ライブラリには送受信だけさせ、
受信データの解釈と応答バッファの作成は
もっと上の階層で行いたいのですが、
一般的にはどういう方法で行うのでしょうか？

121:デフォルトの名無しさん
09/01/13 19:40:06
他人に通じる文章書くようにしましょう。

階層の深いところって何の階層だ？
ライブラリとして意味がなくなるのが自明みたいに書いてるが、
他人にはさっぱり

122:デフォルトの名無しさん
09/01/13 19:51:24
サーバークラスなりが、コールバック動作をするコードになってないってことじゃね。

123:デフォルトの名無しさん
09/01/13 23:35:09
>>120
こういうのを一般化する時の問題はデータの区切りの判定です。　
どこがデータの区切りで、どこまでデータを読んでから上層に渡せばいいかは
プロトコル依存だからです。　パケットのヘッダに長さが埋め込まれている場合、
CR/LFでメッセージの区切りが指定されている場合等、ひどい場合は階層構造の
データを深くパージングしないと切れ目が分からないなどと言う物も。

>>122
が言う様に普通はコールバックを上層が用意し、データの区切りの判断を
これらのコールバックを呼んで判断するという方法です。　区切りの方法によって
どういうコールバックのインターフェースを用意すればいいかは自分で考えましょう。

124:デフォルトの名無しさん
09/01/14 00:32:59
コールバックって・・・
クラスって書いてんじゃん

125:デフォルトの名無しさん
09/01/14 00:51:22
>>124
もしかしてプログラミング初心者？

例えばイベントハンドラで何か動作をさせる、という時に
イベント制御ルーチンにイベントハンドラを登録して
そのイベントハンドラに制御を移すことを「コールバック動作」と言うんだよ。

126:デフォルトの名無しさん
09/01/14 01:09:20
例えばC++で書くなら
class EventLister {
virtual int OnAccept() = 0;
virtual int OnReveive() = 0;
...
};
class Server {
　EventListerner& handler;
　AsyncServer(EventListerner& handler) : handler(handler) {}
　void receiveexec() { // select後に呼び出される
　　handler.OnReceived();
　}
};

のような造りがコールバック動作でしょ。
これで、EventListenerを継承して自分のやりたいことをやるものを作り
コンストラクタに渡すようにすれば、
必要なときにServerからコールバックされるように出来るでしょ。

127:デフォルトの名無しさん
09/01/14 01:17:13
メッセージのクラスと応答のクラスを作ればいいんじゃね

128:デフォルトの名無しさん
09/01/14 02:57:49
>>123
SOCK_STREAMじゃなくてSOCK_RAWを使ってるってこと？

129:デフォルトの名無しさん
09/01/14 09:07:00
ふぁひょふっへって、でへばいいべおいいんじゃねぇぇっぇええぇええの？

130:123
09/01/14 09:41:10
>>124
あ、ごめん、そうだね。　じゃ、C++的には長さ、区切り判定をするメソッドを
virtualで定義し、実装をサブクラスで行うのがいいですね。
>>128
TCP（SOCK_STREAM)という前提で私は話してました。　receiveで受け取ったデータはtcpの
データグラムと一致している保証もないし、データグラムが上位階層の送信単位と一致する
保証もないので切り分けは上位階層の知識が必要になります。　>>120さんはそこらへんの
必要性は分かっているという印象は受けました。

131:デフォルトの名無しさん
09/01/14 10:03:27
>>126
え、それをコールバックって言っちゃうの？

132:120
09/01/14 10:12:36
みなさん回答ありがとうございます。Cっぽくコールバックでやろうと思ってましたが
>>126を参考にしたいと思います。

133:120
09/01/14 10:23:30
デリミタだけは確定しているため、そこだけはスレッドの中でやってしまうつ
もりです。デリミタが来たら受信を終了しコールバックで解釈、応答バッファを作成しも戻ってきたところで、sendさせます。

134:デフォルトの名無しさん
09/01/14 10:27:04
>>131
Wikipedia項目ﾘﾝｸ(%E6%83%85%E5%A0%B1%E5%B7%A5%E5%AD%A6)#.E5.AE.9F.E8.A3.85

135:デフォルトの名無しさん
09/01/14 13:45:30
Java臭がする糞ースだと思った。

136:デフォルトの名無しさん
09/01/14 16:52:06
この問題なんですが、解答あってるでしょうか？

msgbox "変数aの値は"　& a & " , 変数bの値は" & b

この文を先頭から２つ目の&までとその後の部分に分け、正しく２行で記述しなさい。
また、変数a,bの値がそれぞれ１０，２０である場合に、実行したときに表示される
メッセージボックスの中の記述内容を書きなさい。

解答。

msgbox"変数aの値は"　& a &
msgbox"変数bの値は"　&b

変数aの値は　　１０
変数bの値は　　２０

137:デフォルトの名無しさん
09/01/14 16:55:56
誤爆か

138:デフォルトの名無しさん
09/01/14 21:15:59
ウンコマン

139:デフォルトの名無しさん
09/01/15 10:24:38
ネットワークプログラミングの究極の目的は
自分のPCにソフトをインストールしない
ということでしょうか？
つまり自分のPCにエクセルが入ってなくてもネットワーク経由でエクセルがつかえる
のように。
しかし、エクセルの入ってないPCと入っているPCをLANでつないでもエクセルは操作できませんでした。
ところが、詰将棋ソフトはPCに入ってなくてもLAN経由でできました。
これはどういうことなんでしょうか？

140:デフォルトの名無しさん
09/01/15 11:42:25

　　　　

？

141:デフォルトの名無しさん
09/01/15 11:44:48

？

142:デフォルトの名無しさん
09/01/15 12:45:19
>>139
>ネットワークプログラミングの究極の目的は
>自分のPCにソフトをインストールしない
>ということでしょうか？
>つまり自分のPCにエクセルが入ってなくてもネットワーク経由でエクセルがつかえる
>のように。

それはただのクラウドコンピューティングの一環。
ネットワークプログラムそのものに目的はないんじゃないか。
目的を達成する手段の一つとしてネットワークプログラミングがあるだけで。

>しかし、エクセルの入ってないPCと入っているPCをLANでつないでもエクセルは操作できませんでした。
>ところが、詰将棋ソフトはPCに入ってなくてもLAN経由でできました。
>これはどういうことなんでしょうか？

知るか。
ソフトの仕様による。
どうしても操作したけりゃRealVNCでも突っ込んどく？
チェケラッチョ
URLﾘﾝｸ(www.vector.co.jp)

143:デフォルトの名無しさん
09/01/15 22:00:55
誰かWinsockでUDPで音声を送信して、受信して再生するプログラムのCかC++の
サンプルソースください。
ボイスチャットみたいなものを作ってみたいのです。

UDPで音声データを送信～受信的なところまでは分かるのですが、
受信したものをどうやって再生するんだよ！という状態です。

１回ファイルに書き込んでそれを再生というのも冗長な気もしますし、
だからと言ってPlaySoundでもメモリ上から～というのも
エンドレスで受信されるデータにどう対応して良いか分かりません。

ググっても、『音声や動画のようなものにはUDP！』というところまでしか出てきません。

ヒントでも参考URLでも良いのでお願い致します。

144:デフォルトの名無しさん
09/01/15 22:11:36
「voice chat　使用言語」でググればいっぱい海外サイト出る

145:デフォルトの名無しさん
09/01/15 22:47:31
>>144
ありがとうございます！
母国語以外を無意識に避けていて気付きませんでした！
私のような愚か者がいるから日本の国力が低下するのですね！
これからは他のことでも進んで他国語からも情報を得る努力をします！
１人でも国力底上げしてやるぜYEAH！！！！

146:デフォルトの名無しさん
09/01/16 13:24:15
YEAH！！！！

147:デフォルトの名無しさん
09/01/16 19:14:35
ふつーwave～系APIとか、DirectSoundとか
DirectShowとか使うと思う。というか、受信した
データをどうするかはスレ違いか。

148:デフォルトの名無しさん
09/01/16 23:05:49
>>143
>>102 javaだけどね。

149:デフォルトの名無しさん
09/01/16 23:14:56
なにを言ってるんだ

150:デフォルトの名無しさん
09/01/17 13:05:27
質問です
WindowsのVC++でネットワークのアプリを作成しているのですが、通信速度を制限して通信する方法ってありますか？
例えば最大でも30kbpsまでしか速度を出さないように送受信するにはどうすればよいでしょうか？

151:デフォルトの名無しさん
09/01/17 13:12:15
>>150
１秒毎に4kバイトずつsendを呼べばいいんじゃね？

152:デフォルトの名無しさん
09/01/17 13:14:18
1. ネットワークドライバを作る
2. 例えば最大でも30kbpsまでしか速度を出さないように送受信する
3. そんなの作らずにあるもの使えばいいじゃん

153:デフォルトの名無しさん
09/01/17 13:35:52
ダウンロードならBITS使うという手があるんだがなー

154:デフォルトの名無しさん
09/01/18 01:24:29
>>151-153
㌧

155:デフォルトの名無しさん
09/01/20 15:38:38

156:デフォルトの名無しさん
09/01/21 01:28:32
なんかCやC++で作成してる人が多いみたいだけど、
サーバーで送受信部分をPHPとかで作ってる人って居ないの？

157:デフォルトの名無しさん
09/01/21 10:25:56
PHPでやる意味がない。

158:デフォルトの名無しさん
09/01/21 11:23:26
そういやレンタル鯖にperlの串置いて踏み台にするとか昔流行ったな
まあphpは板違いだな

159:デフォルトの名無しさん
09/01/21 19:54:19
パケットキャプチャしてみたがIPフラグメントがされてない
あきらかに64kb以上のデータを取得しているのにどうしてなんだ！

160:デフォルトの名無しさん
09/01/21 21:56:16
１パケットって何バイトだった？

161:デフォルトの名無しさん
09/01/21 22:04:02
バケラッタ！

162:デフォルトの名無しさん
09/01/21 22:28:43
TCP送信に関して以下の認識でOK？

｢デーーーーーーーータ｣
↓
データを分割
｢データ｣、｢データ｣、｢データ｣
↓
IP付けて送信
IP head+TCP Head+｢データ｣ , IP he～～～

それと、
IP head+TCP Head+｢データ｣から｢デーーーーーーーータ｣に
再構築するソース教えてくれ

163:デフォルトの名無しさん
09/01/21 22:55:22
｢デーーーーーーーータ｣
↓
データを分割
｢デーーー｣、｢ーー｣、｢ーーータ｣
↓
IP付けて送信
IP head+TCP Head+｢データ｣ , IP he～～～
↓
受信
｢ーーータ｣、｢ーー｣、｢デーーー｣

164:デフォルトの名無しさん
09/01/21 23:04:55
TCPはスライド窓だからターデはありえない

165:デフォルトの名無しさん
09/01/21 23:16:05
http～ 001.zipをダウンロードしているとき（web閲覧時も
IPヘッダみてもFlagが分割不可になっているのはなぜ？
パケットの取得方法は、PacketFilterExtensionPtr関数。

166:デフォルトの名無しさん
09/01/22 00:19:29
皆さん如何されているかアイデアを聞かせてほしいんですが

たとえば、不特定多数が使用するクライアント・サーバ型のソフト(MMO等)を作るとして、
データのやり取りはUDPで行うとします。
不正なデータを送られたり、受信したデータから不正な処理をされないためには
データを暗号化して通信する必要がありますが、そのキーを何処に隠すとよいと思いますか？

クライアント側で暗号化したデータをサーバで復号する、またその逆の場合、
クライアントはサーバと通信する為に、鍵を持っている必要がありますが
コード上やリソース上に持たせてしまうと、バイナリエディタなどからバレてしまう可能性があります。

ここで、脅威の対象を仮に
・28歳　男性　独身
･趣味はネトゲ(botツール常習者)
・プログラミングの知識は大学で習った程度、逆アセンブルなどは出来ない
・バイナリエディタなどでパラメータを触った経験はあり
とします。この人にクラックされない仕組みを作りたいです。

色々考えましたが堂々巡りです。

案1)通信確立用のキーをクライアントのコード上、またはリソース上に持たせ、
　　通信確立はそのキーで行う。その後はサーバで新たなキーを発行する。
→そもそも通信確立用のキーがクラックされれば全く意味が無い

案2)時刻をパラメータに定期的にキーを生成する。
→クライアント・サーバで完全に時刻を同期する必要あり。実現不可能

案3)暗号化部分をdll化し、さらにそのdllを暗号化し、コード上で復号して呼び出す。
　　dllを暗号化したキーはリソース化し、リンク
→トレースされたら意味なし

よいアイデアお待ちしてます。

167:デフォルトの名無しさん
09/01/22 00:26:50
暗号についての教科書でも読め

168:デフォルトの名無しさん
09/01/22 00:30:47
>>166
普通に非対称鍵暗号使えばいいんじゃ

169:デフォルトの名無しさん
09/01/22 00:32:48
共通鍵方式であれ公開鍵方式であれ鍵の扱い方は教科書には載ってない

170:166
09/01/22 00:40:06
>167-169

『コード上に載っている鍵をバイナリエディタなどで不正に読み出し、
正規とは別のデータを暗号化し、サーバからみたら「正常な」データを送りつける』のが
BOTツールだと思うので、対象鍵であれ非対象鍵であれ、
暗号化に使う鍵がばれてしまう事自体が問題だと思うんですが。

というか、世に出回っているネットワークプログラムは、どういう対策をとっているのだろうか・・

171:デフォルトの名無しさん
09/01/22 00:40:23
>>166
通信確立用のキーがクラックされることを考えるなら、
復号直後のデータを抜かれるクラックも想定が必要ということ?

いずれにしても通信経路上の他人に隠すならともかく、
PCの所有者にその想定で隠すのは無理と思う

172:166
09/01/22 00:44:55
>>171
幾ら対策してもMMOにBOTツールやアカウントハックが無くならないのはやはり仕方がないのでしょうか。
どれだけ厳重な金庫にお金を隠しても、金庫の鍵がそこにあれば泥棒は簡単に取っていけますからね。

173:デフォルトの名無しさん
09/01/22 00:50:25
通信の傍受は防げてもプログラムのクラックはいたちごっこだな

174:デフォルトの名無しさん
09/01/22 03:48:20
>>166
正規なクライアントだけが持っている情報は一切全く無い、と仮定
するけど、正規なクライアントだけ通信できるようにしたい、ってのは
原理的に不可能だと思う。

ただ、MMO なら、ユーザごとにアカウントとパスワードで接続してるので
それを秘密キーにすれば、正規クライアントかどうか判定はできるんじゃないかな

現実的には案１で十分だと思う。クライアントソフトのクラックは別途対策する
(nProtectとか）ことが多いかと

175:デフォルトの名無しさん
09/01/22 11:13:02
中間者攻撃というのがあってだな…。

昔P2Pで適当なループ作って署名付けて二回回すってのを考えたけど
結論覚えてないや(w

次ページ