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

1 ：デフォルトの名無しさん：2008/12/28(日) 21:07:24

主にソケットに関しての質疑応答スレッドです。

Programming 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辺り
足りなかったら適当に付け足してね

前スレ
ネットワークプログラミング相談室 Port22
http://pc11.2ch.net/test/read.cgi/tech/1222603744/
関連スレ
Java ネットワークプログラミング【教えて!】
http://pc11.2ch.net/test/read.cgi/tech/1086238859/

2 ：デフォルトの名無しさん：2008/12/28(日) 21:09:27

3 ：デフォルトの名無しさん：2008/12/28(日) 21:10:03

図書コーナー:
UNIXネットワークプログラミング〈Vol.1〉ネットワークAPI:ソケットとXTI
　http://www.amazon.co.jp/exec/obidos/ASIN/4894712059/
　そのソースコード
　http://www.unpbook.com/src.html
詳解TCP/IP〈Vol.1〉プロトコル
　http://www.amazon.co.jp/exec/obidos/ASIN/4894713209/
詳解TCP/IP〈Vol.2〉実装
　http://www.amazon.co.jp/exec/obidos/ASIN/4894714957/
詳解TCP/IP〈Vol.3〉トランザクションTCP, HTTP, NNTP, UNIXドメインプロトコル
　http://www.amazon.co.jp/exec/obidos/ASIN/4894716674/
TCP/IPによるネットワーク構築
　〈Vol.1〉原理・プロトコル・アーキテクチャ
　　http://www.amazon.co.jp/exec/obidos/ASIN/432012054X/
　〈Vol.3〉クライアント‐サーバプログラミングとアプリケーション
　　http://www.amazon.co.jp/exec/obidos/ASIN/4320028007/
　　Linux/POSIXソケットバージョン
　　http://www.amazon.co.jp/exec/obidos/ASIN/4320120841/
　　Windowsソケットバージョン
　　http://www.amazon.co.jp/exec/obidos/ASIN/4320029992/

4 ：デフォルトの名無しさん：2008/12/28(日) 21:10:34

マスタリングTCP/IP RTP編
　http://www.amazon.co.jp/exec/obidos/ASIN/4274065618/
Linuxソケットプログラミング?ネットワークプログラミングにおける実践技法
　http://www.amazon.co.jp/exec/obidos/ASIN/4894714671/
Webプロトコル詳解?HTTP/1.1、Webキャッシング、トラフィック特性分析
　http://www.amazon.co.jp/exec/obidos/ASIN/4894715414/
WinSock2.0プログラミング
　http://www.amazon.co.jp/exec/obidos/ASIN/4797306882/
猫でもわかるネットワークプログラミング
　http://www.amazon.co.jp/exec/obidos/ASIN/4797323604/
IPv6ネットワークプログラミング
　http://www.amazon.co.jp/exec/obidos/ASIN/4756142362/
Visual Basicではじめるネットワークプログラミング超入門
　http://www.amazon.co.jp/exec/obidos/ASIN/4839917523/

5 ：デフォルトの名無しさん：2008/12/28(日) 21:12:04

URL抜粋:
★規格
RFC 日本語版リスト
　http://www5d.biglobe.ne.jp/~stssk/rfcjlist.html
JPNIC RFC関連リンク集
　http://rfc-jp.nic.ad.jp/link/
RFC Editor
　http://www.rfc-editor.org/
HTMLなRFC (セクションを直に示すのに便利)
　http://www.freesoft.org/CIE/RFC/
RFC 2616 "Hypertext Transfer Protocol -- HTTP/1.1" 日本語訳
　http://www.studyinghttp.net/cgi-bin/rfc.cgi?2616
IANA Well known port numbers
　http://www.iana.org/assignments/port-numbers

6 ：デフォルトの名無しさん：2008/12/28(日) 21:17:04

★プログラミング
C10K ヘヴィーロードサーバ
　http://www.kegel.com/c10k.html
C10K ヘヴィーロードサーバ(日本語訳)
http://www.hyuki.com/yukiwiki/wiki.cgi?TheC10kProblem
MSDN
　http://msdn.microsoft.com/library/en-us/dnsitehelp/html/tochelp.asp
Raw IP Networking FAQ
　http://www.whitefang.com/rin/
Java で packet capture
　http://netresearch.ics.uci.edu/kfujii/jpcap/doc/
Randomness Recommendations for Security
　http://www.faqs.org/rfcs/rfc1750.html
BoostSocket
　http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostSocket
The Code Project - Internet & Network programming
　http://www.codeproject.com/internet/
ネットワークプログラミングの基礎知識 (問題ありのサイト?)
　http://X68000.q-e-d.net/~68user/net/

7 ：デフォルトの名無しさん：2008/12/28(日) 21:20:20

★ツール類
ethereal - http://www.ethereal.com/
Wireshark - http://www.wireshark.org/
tcpdump - http://www.tcpdump.org/
Windump - http://netgroup-serv.polito.it/netgroup/tools.html
WinPcap - http://www.winpcap.org/
pathchar - ftp://ftp.ee.lbl.gov/pathchar/
pchar - http://www.employees.org/~bmah/Software/pchar/
Packetyzer - http://www.networkchemistry.com/products/packetyzer/
libevent - http://www.monkey.org/~provos/libevent/

★プロトコル
TTCP
　http://www.sean.de/Solaris/ttcp.html
　http://www.kohala.com/start/ttcp.html
UDP Hole Punching
　http://homepage3.nifty.com/toremoro/p2p/firewall.html

★IP, TCP実装
http://www.iti.fi/documentation/miniip.html
http://www.sics.se/~adam/uip/
http://www.codeguru.com/Cpp/I-N/network/tcpip/article.php/c5447/
http://www.geocities.jp/bruce_teller/security/garakuta.htm

8 ：デフォルトの名無しさん：2008/12/28(日) 21:21:38

>>2
過去スレ：
Port20 http://pc11.2ch.net/test/read.cgi/tech/1086238859/

9 ：デフォルトの名無しさん：2008/12/28(日) 22:02:40

10 ：デフォルトの名無しさん：2008/12/28(日) 22:05:15

乙

11 ：デフォルトの名無しさん：2008/12/28(日) 22:27:12

Ｚ

12 ：デフォルトの名無しさん：2008/12/28(日) 23:03:06

Port22 の977ですが、
closeの戻り値はチェックしてましたが、ちゃんと0が返ってきてました。
libevent内部で何をしてるかはまだ見れていないですが、
とりあえず共有しておきます。

13 ：デフォルトの名無しさん：2008/12/28(日) 23:38:05

epollやkqueueあたりの仕組みってWindowsじゃどうなってんだろ?

14 ：デフォルトの名無しさん：2008/12/28(日) 23:51:18

IOCPや重複I/O
WSAEventSelectやWSAAsyncSelectもね

15 ：デフォルトの名無しさん：2008/12/29(月) 00:25:34

IOCPはともかく、
重複I/Oはepoll/kqueueとは違うでしょ。
aio_*あたりでしょ。

16 ：デフォルトの名無しさん：2008/12/29(月) 04:34:24

Port23 って telnet か

17 ：デフォルトの名無しさん：2008/12/31(水) 13:27:03

18 ：【大吉】：2009/01/01(木) 09:39:47

19 ：デフォルトの名無しさん：2009/01/01(木) 18:45:20

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

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

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

20 ：デフォルトの名無しさん：2009/01/01(木) 18:52:49

19です。ちなみに、linux上でpthreadを使っています。

21 ：デフォルトの名無しさん：2009/01/01(木) 19:20:57

>処理数が処理スレッド数を上回った場合は、管理スレッドが処理スレッドを増やすなどを行う

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

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

22 ：デフォルトの名無しさん：2009/01/01(木) 20:05:11

大抵破綻しないが、破綻することもある、だろ

23 ：デフォルトの名無しさん：2009/01/01(木) 20:19:51

大抵破綻するだろ

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

24 ：デフォルトの名無しさん：2009/01/01(木) 20:32:13

>> 処理数が処理スレッド数を上回った場合は、管理スレッドが
>> 処理スレッドを増やすなどを行う

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

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

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

25 ：デフォルトの名無しさん：2009/01/01(木) 20:39:22

>>24
素人なの？

26 ：デフォルトの名無しさん：2009/01/01(木) 20:40:35

＞増やす上限決めときゃ良いだけの話しだし

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

27 ：デフォルトの名無しさん：2009/01/01(木) 20:42:02

破綻するかもしれないが、そうじゃないように使う、とかいう設計はやばいな。

28 ：デフォルトの名無しさん：2009/01/01(木) 20:43:54

>>26
スレッドプールにして～　というくだりをみて言ってるっぽいので、
アホなんでしょう。

29 ：デフォルトの名無しさん：2009/01/01(木) 20:48:35

>>19
スレッドはどういう順番で動くか基本的には操作できないので、
セマフォとか駆使してやってみるのがいいんジャマイカ？

30 ：デフォルトの名無しさん：2009/01/01(木) 20:52:37

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

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

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

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

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

31 ：デフォルトの名無しさん：2009/01/01(木) 20:55:34

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

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

32 ：デフォルトの名無しさん：2009/01/01(木) 20:56:03

pthread_createするのはコストがかかるんだよｗｗｗ

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

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

33 ：デフォルトの名無しさん：2009/01/01(木) 20:57:59

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

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

34 ：デフォルトの名無しさん：2009/01/01(木) 20:59:36

スレッドプールってふつうは上限を設定するだろ。
なんなんだこの話の流れは？

35 ：デフォルトの名無しさん：2009/01/01(木) 21:01:09

言語は何だ？

36 ：デフォルトの名無しさん：2009/01/01(木) 21:02:19

>>32
だから Apache のドキュメントでも読んでこいよ。
無駄にスレッド作るとリソース食うからああいう構成にしてるんだし。

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

37 ：デフォルトの名無しさん：2009/01/01(木) 21:04:14

自分で自分の日本語の不自由さを責めなくていいんだよｗ

38 ：デフォルトの名無しさん：2009/01/01(木) 21:05:23

大抵わかってない奴は意味不明な言い訳をして日本語云々言いたがる
これはその典型です。

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

39 ：デフォルトの名無しさん：2009/01/01(木) 21:09:22

けんかはやめるんだ

40 ：デフォルトの名無しさん：2009/01/01(木) 21:10:26

俺もよくわからない。

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

41 ：デフォルトの名無しさん：2009/01/01(木) 21:12:16

ムカついて反論したいだけだろ

42 ：デフォルトの名無しさん：2009/01/01(木) 21:20:09

かみ合わないことに気付かないで日本語指摘してるやついるのか。
世も末だな。

43 ：デフォルトの名無しさん：2009/01/01(木) 21:42:40

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

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

44 ：デフォルトの名無しさん：2009/01/01(木) 21:57:51

キレたのは別の人でしょ。この流れをどう見ても。

45 ：デフォルトの名無しさん：2009/01/01(木) 21:59:32

アパッチ云々ではなくて、マルチスレッドの使い方の話だろこれ・・・

46 ：デフォルトの名無しさん：2009/01/01(木) 22:05:54

>> 処理数が処理スレッド数を上回った場合は、管理スレッドが
>> 処理スレッドを増やすなどを行う

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

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

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

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

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

47 ：デフォルトの名無しさん：2009/01/01(木) 22:08:07

本とどうでもいい。新年からやめろおまいら。

48 ：デフォルトの名無しさん：2009/01/01(木) 22:20:18

一番の問題は、質問が曖昧なことだ

49 ：デフォルトの名無しさん：2009/01/01(木) 22:21:40

なんにでもケチつけるんだな、おまえ

50 ：デフォルトの名無しさん：2009/01/01(木) 22:23:24

>>21=>>46
相変わらず、何を言いたいのかさっぱりわからん。(w

>>48
同意。

51 ：デフォルトの名無しさん：2009/01/01(木) 22:26:01

>>21が何を言っているのかわからないということはないだろう。
日本語不自由ではなくて、君の技術的に問題があるんじゃないか？>>50よ。

52 ：デフォルトの名無しさん：2009/01/01(木) 22:28:00

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

53 ：デフォルトの名無しさん：2009/01/01(木) 22:30:15

>>52
もはやそんな話から始めなければならなくなったかｗｗｗ

54 ：デフォルトの名無しさん：2009/01/01(木) 22:33:29

まあ素人向けですから。

55 ：デフォルトの名無しさん：2009/01/01(木) 22:35:17

マルチスレッドスレッドｗに行ってくれ

56 ：デフォルトの名無しさん：2009/01/01(木) 22:40:52

最初に全部のスレッド作ると効率悪いから
最初いくつか作っておいて、それで足りなくなったらある単位ごとに継ぎ足す、
でも上限に達するとエラー、ってのが基本だろう。

57 ：デフォルトの名無しさん：2009/01/01(木) 22:45:19

スレッド数が上限に達してもエラーにはならんよ（ってか、エラーにはしない）。
プールに戻ってくるまでwaitするだろ普通。

58 ：デフォルトの名無しさん：2009/01/01(木) 22:45:54

>>57
そこはあえて突っ込むべきか迷ってたんだがな

59 ：デフォルトの名無しさん：2009/01/01(木) 22:48:02

JavaのAPIでもスレッドプールあるけど、
いくつか種類がある。

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

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

60 ：デフォルトの名無しさん：2009/01/01(木) 22:49:39

スレッドプールを使い切ったらエラーなんてありえねぇよ。
わざとそういう仕様にしない限りね。

61 ：デフォルトの名無しさん：2009/01/01(木) 22:54:14

話ぶった切って悪いけど、
googleやyahoo等のwebサーバって、どのくらいの数のユーザスレッドもしくはプロセスが上がるんですか？
10万人が一度に接続してきたとき、10万スレッドが作られるんですか？

62 ：デフォルトの名無しさん：2009/01/01(木) 22:55:34

サーバー１台じゃないだろ JK

63 ：デフォルトの名無しさん：2009/01/01(木) 22:57:21

女子高生と聞いてやってきました

64 ：デフォルトの名無しさん：2009/01/01(木) 22:58:09

全部のサーバーがマルチスレッド対応で1リクエストごとに1スレッド作るんだったら全部のサーバーの合計スレッド数は10万になるだろうな

65 ：デフォルトの名無しさん：2009/01/01(木) 23:03:07

>>61
世の中にはサーバ負荷分散を行うアプライアンス装置ってもんがある JK

66 ：デフォルトの名無しさん：2009/01/02(金) 00:14:39

接続の数だけスレッドがある状態だと性能が劣化すると思うが、
なぜそんな構成にするのか？

67 ：デフォルトの名無しさん：2009/01/02(金) 02:14:49

いきなりレス数増えてると思ったら新年からファビョってんのかｗ

68 ：デフォルトの名無しさん：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 ：デフォルトの名無しさん：2009/01/05(月) 15:35:17

＞その後一分以内に（モデムのポートが開いている間に）
これが謎だ

70 ：デフォルトの名無しさん：2009/01/05(月) 15:46:46

もでむ、つか、NAPT?

71 ：68：2009/01/05(月) 15:57:52

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

72 ：デフォルトの名無しさん：2009/01/05(月) 18:47:20

>>68
あんたの言う「モデム」っていうのは、いわゆるブロードバンドルータの類の
NATルータを指してるんでしょ(モデムと言うと違うものになるから、みんな混乱する)。

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

73 ：68：2009/01/06(火) 03:15:16

解答ありがとうございました。
実はuPnPを使うことで解決してしまいました。

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

74 ：デフォルトの名無しさん：2009/01/06(火) 07:54:35

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

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

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

75 ：デフォルトの名無しさん：2009/01/06(火) 09:29:04

LAN内なのかVPNなのかインターネット通して送るのかにもよるんじゃね

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

76 ：デフォルトの名無しさん：2009/01/06(火) 11:23:53

>>74
たとえば mpeg には他のフレームを参照すること無しに
画面を構築できる I-frame があるから、UDP でパケッ
ト落しても次の I-frame から普通に再生できる。

http://vsr.informatik.tu-chemnitz.de/~jan/MPEG/HTML/mpeg_tech.html

77 ：デフォルトの名無しさん：2009/01/06(火) 11:36:52

完全なデータがほしければTCP,データが落ちてもいいならUDP
でいいんじゃないかと

78 ：デフォルトの名無しさん：2009/01/06(火) 11:42:19

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

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

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

79 ：デフォルトの名無しさん：2009/01/06(火) 19:35:35

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

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

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

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

80 ：デフォルトの名無しさん：2009/01/06(火) 19:48:12

あ、あと気になったのは
> 試しに、サンプルを作って評価すると、
> ロスパケットが多すぎるのでは？と感じています。

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

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

81 ：デフォルトの名無しさん：2009/01/07(水) 16:52:49

http://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 ：デフォルトの名無しさん：2009/01/07(水) 17:39:41

>>81
WSACleanup()を呼ばなければならない。
main()で「return -1」とか、センスの悪そうなプログラムだね。

83 ：デフォルトの名無しさん：2009/01/07(水) 17:55:43

呼ばなくてもOSがよろしくやってくれて問題起きることはなさそうだけどな。
malloc論争みたいなもんか。

84 ：81：2009/01/07(水) 18:12:54

>>82-83
なるほど、ありがとうございます。
mallocについても調べてみます。

85 ：デフォルトの名無しさん：2009/01/07(水) 18:16:57

MSDN的にはWSACleanup()は「must call」だそうだが、いまどきの
Windowsならたぶん実害はないっぽ。

86 ：デフォルトの名無しさん：2009/01/07(水) 19:06:17

>>81
WSACleanup() はプログラム終了時に一度だけ呼べば良
いので（というか処理を継続するなら呼んではいけない
ので）、ソケット作成失敗とかそういう細々したエラー
では呼ばない方が良いと思う。

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

87 ：デフォルトの名無しさん：2009/01/07(水) 19:11:20

>>86
もとのコードを良く読みましょう。
main()からreturnしているのです。

88 ：デフォルトの名無しさん：2009/01/07(水) 19:29:36

atexit

89 ：デフォルトの名無しさん：2009/01/07(水) 19:58:55

どうせOSが開放するんだからWSACleanupは呼ばなくていいのでは？
なんかまずい事あるかな。

90 ：デフォルトの名無しさん：2009/01/07(水) 20:04:03

呼ぶ必要はないと書かれてないなら呼んだ方がいいだろ

91 ：デフォルトの名無しさん：2009/01/07(水) 22:26:14

>>86
> WSACleanup() はプログラム終了時に一度だけ呼べば良
> い

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

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

92 ：デフォルトの名無しさん：2009/01/07(水) 23:27:17

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

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

93 ：デフォルトの名無しさん：2009/01/08(木) 15:12:07

プロセス終了時に一回呼び出すだけで良いんだから、
ぐだぐだ言わずに書いとけや、とも思うしね。それで困ることなんてないでしょ。

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

94 ：デフォルトの名無しさん：2009/01/08(木) 17:48:29

mallocの場合は自分でfreeするよりOSがごっそり切り離すほうが効率いいんじゃないの？と信じてあえて書かない

95 ：デフォルトの名無しさん：2009/01/08(木) 17:58:50

終了前freeはまあモダンな仮想メモリ実装したOSじゃ意味ねーな

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

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

96 ：デフォルトの名無しさん：2009/01/08(木) 18:36:36

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

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

97 ：96：2009/01/08(木) 18:37:10

スレタイをよく見たらスレ違い気味だったね、すまん

98 ：デフォルトの名無しさん：2009/01/08(木) 23:45:10

>Winsock Programmer's FAQ (日本語訳)
>http://www.kt.rim.or.jp/~ksk/wskfaq-ja/

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

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

99 ：デフォルトの名無しさん：2009/01/09(金) 01:59:17

>>98
自己解決しました。（Winsock IOCPでGoogle検索したら
欲しい情報がいっぱい見つかりました）

100 ：デフォルトの名無しさん：2009/01/09(金) 09:54:07

boost::asioってここのスレ的にどうなの？全く話題に出ないが。
boostスレはともかくとして

101 ：デフォルトの名無しさん：2009/01/09(金) 19:19:07

boostスレの方がよさげ

102 ：デフォルトの名無しさん：2009/01/09(金) 22:23:40

ttp://www.nicovideo.jp/watch/sm5774030
このｽﾚの住人的にはｺﾚどうですか？

103 ：デフォルトの名無しさん：2009/01/10(土) 04:06:09

さあ・・
ハードで作ったほうが面白いのでは

104 ：デフォルトの名無しさん：2009/01/10(土) 07:38:48

ttp://jp.youtube.com/watch?v=SmHjQMki32E&NR=1
このｽﾚの住人的にはｺﾚどうですか？

105 ：デフォルトの名無しさん：2009/01/10(土) 08:32:38

さあ・・
隣の芝生は赤かったってことでは

106 ：デフォルトの名無しさん：2009/01/11(日) 20:10:55

std::istream的なソケットストリームってなぜ作られないんですかね？

107 ：デフォルトの名無しさん：2009/01/11(日) 20:40:47

使いにくいからじゃね？selectとかasyncとかしたいし。
そうでない単純なものなら自分でサクッと作れる（たぶん）し。

108 ：デフォルトの名無しさん：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 ：デフォルトの名無しさん：2009/01/11(日) 21:01:58

socketのようにいつデータが受信されるかわからないものを同期で組むのは面倒だぞ。

112 ：デフォルトの名無しさん：2009/01/11(日) 21:06:03

>>110
１スレッド１コネクションでも問題は無いけどね。ネットワークプログラミングの難しさはエラー処理にある。

113 ：デフォルトの名無しさん：2009/01/11(日) 21:17:33

>>109
可能だよ。現実にコネクションを標準入出力にリダイレクトするソフトがある。

114 ：デフォルトの名無しさん：2009/01/11(日) 21:25:09

boost::asioは調べてみたことがあるんですが、あれはパフォーマンスのために
非同期対応にしてるけど結果的にうまくいっていない感じでしたね。

115 ：デフォルトの名無しさん：2009/01/11(日) 21:28:19

>>114
それってどういうこと？
非同期モデルは採用したが、それに見合うパフォーマンスが出ていないという話なのか
iostreamベースのラッパーとの相性が悪いという話なのか

116 ：デフォルトの名無しさん：2009/01/11(日) 21:29:02

iostreamはともかく
stdioのFILEとして扱うのはそれなりには使われてるってば。

117 ：デフォルトの名無しさん：2009/01/11(日) 21:29:55

>>116
それはブロッキングでやってfdopen()して
タイムアウトはalarm()でって古式ゆかしき方法だよな

118 ：デフォルトの名無しさん：2009/01/11(日) 21:50:21

>>115
重複IOを活かす為の苦心が感じ取れるが、複雑化してしまった感じ。

119 ：デフォルトの名無しさん：2009/01/11(日) 21:51:19

>>118
ああ、早い話が綺麗じゃないってことか

120 ：デフォルトの名無しさん：2009/01/13(火) 18:39:57

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

121 ：デフォルトの名無しさん：2009/01/13(火) 19:40:06

他人に通じる文章書くようにしましょう。

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

122 ：デフォルトの名無しさん：2009/01/13(火) 19:51:24

サーバークラスなりが、コールバック動作をするコードになってないってことじゃね。

123 ：デフォルトの名無しさん：2009/01/13(火) 23:35:09

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

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

124 ：デフォルトの名無しさん：2009/01/14(水) 00:32:59

コールバックって・・・
クラスって書いてんじゃん

125 ：デフォルトの名無しさん：2009/01/14(水) 00:51:22

>>124
もしかしてプログラミング初心者？

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

126 ：デフォルトの名無しさん：2009/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 ：デフォルトの名無しさん：2009/01/14(水) 01:17:13

メッセージのクラスと応答のクラスを作ればいいんじゃね

128 ：デフォルトの名無しさん：2009/01/14(水) 02:57:49

>>123
SOCK_STREAMじゃなくてSOCK_RAWを使ってるってこと？

129 ：デフォルトの名無しさん：2009/01/14(水) 09:07:00

ふぁひょふっへって、でへばいいべおいいんじゃねぇぇっぇええぇええの？

130 ：123：2009/01/14(水) 09:41:10

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

131 ：デフォルトの名無しさん：2009/01/14(水) 10:03:27

>>126
え、それをコールバックって言っちゃうの？

132 ：120：2009/01/14(水) 10:12:36

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

133 ：120：2009/01/14(水) 10:23:30

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

134 ：デフォルトの名無しさん：2009/01/14(水) 10:27:04

>>131
http://ja.wikipedia.org/wiki/%E3%82%B3%E3%83%BC%E3%83%AB%E3%83%90%E3%83%83%E3%82%AF_(%E6%83%85%E5%A0%B1%E5%B7%A5%E5%AD%A6)#.E5.AE.9F.E8.A3.85

135 ：デフォルトの名無しさん：2009/01/14(水) 13:45:30

Java臭がする糞ースだと思った。

136 ：デフォルトの名無しさん：2009/01/14(水) 16:52:06

この問題なんですが、解答あってるでしょうか？

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

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

解答。

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

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

137 ：デフォルトの名無しさん：2009/01/14(水) 16:55:56

誤爆か

138 ：デフォルトの名無しさん：2009/01/14(水) 21:15:59

ウンコマン

139 ：デフォルトの名無しさん：2009/01/15(木) 10:24:38

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

140 ：デフォルトの名無しさん：2009/01/15(木) 11:42:25

　　　　

？

141 ：デフォルトの名無しさん：2009/01/15(木) 11:44:48

？

142 ：デフォルトの名無しさん：2009/01/15(木) 12:45:19

>>139
>ネットワークプログラミングの究極の目的は
>自分のPCにソフトをインストールしない
>ということでしょうか？
>つまり自分のPCにエクセルが入ってなくてもネットワーク経由でエクセルがつかえる
>のように。

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

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

知るか。
ソフトの仕様による。
どうしても操作したけりゃRealVNCでも突っ込んどく？
チェケラッチョ
ttp://www.vector.co.jp/soft/win95/net/se324464.html

143 ：デフォルトの名無しさん：2009/01/15(木) 22:00:55

誰かWinsockでUDPで音声を送信して、受信して再生するプログラムのCかC++の
サンプルソースください。
ボイスチャットみたいなものを作ってみたいのです。

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

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

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

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

144 ：デフォルトの名無しさん：2009/01/15(木) 22:11:36

「voice chat　使用言語」でググればいっぱい海外サイト出る

145 ：デフォルトの名無しさん：2009/01/15(木) 22:47:31

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

146 ：デフォルトの名無しさん：2009/01/16(金) 13:24:15

YEAH！！！！

147 ：デフォルトの名無しさん：2009/01/16(金) 19:14:35

ふつーwave～系APIとか、DirectSoundとか
DirectShowとか使うと思う。というか、受信した
データをどうするかはスレ違いか。

148 ：デフォルトの名無しさん：2009/01/16(金) 23:05:49

>>143
>>102 javaだけどね。

149 ：デフォルトの名無しさん：2009/01/16(金) 23:14:56

なにを言ってるんだ

150 ：デフォルトの名無しさん：2009/01/17(土) 13:05:27

質問です
WindowsのVC++でネットワークのアプリを作成しているのですが、通信速度を制限して通信する方法ってありますか？
例えば最大でも30kbpsまでしか速度を出さないように送受信するにはどうすればよいでしょうか？

151 ：デフォルトの名無しさん：2009/01/17(土) 13:12:15

>>150
１秒毎に4kバイトずつsendを呼べばいいんじゃね？

152 ：デフォルトの名無しさん：2009/01/17(土) 13:14:18

1. ネットワークドライバを作る
2. 例えば最大でも30kbpsまでしか速度を出さないように送受信する
3. そんなの作らずにあるもの使えばいいじゃん

153 ：デフォルトの名無しさん：2009/01/17(土) 13:35:52

ダウンロードならBITS使うという手があるんだがなー

154 ：デフォルトの名無しさん：2009/01/18(日) 01:24:29

>>151-153
㌧

155 ：デフォルトの名無しさん：2009/01/20(火) 15:38:38

156 ：デフォルトの名無しさん：2009/01/21(水) 01:28:32

なんかCやC++で作成してる人が多いみたいだけど、
サーバーで送受信部分をPHPとかで作ってる人って居ないの？

157 ：デフォルトの名無しさん：2009/01/21(水) 10:25:56

PHPでやる意味がない。

158 ：デフォルトの名無しさん：2009/01/21(水) 11:23:26

そういやレンタル鯖にperlの串置いて踏み台にするとか昔流行ったな
まあphpは板違いだな

159 ：デフォルトの名無しさん：2009/01/21(水) 19:54:19

パケットキャプチャしてみたがIPフラグメントがされてない
あきらかに64kb以上のデータを取得しているのにどうしてなんだ！

160 ：デフォルトの名無しさん：2009/01/21(水) 21:56:16

１パケットって何バイトだった？

161 ：デフォルトの名無しさん：2009/01/21(水) 22:04:02

バケラッタ！

162 ：デフォルトの名無しさん：2009/01/21(水) 22:28:43

TCP送信に関して以下の認識でOK？

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

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

163 ：デフォルトの名無しさん：2009/01/21(水) 22:55:22

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

164 ：デフォルトの名無しさん：2009/01/21(水) 23:04:55

TCPはスライド窓だからターデはありえない

165 ：デフォルトの名無しさん：2009/01/21(水) 23:16:05

http～ 001.zipをダウンロードしているとき（web閲覧時も
IPヘッダみてもFlagが分割不可になっているのはなぜ？
パケットの取得方法は、PacketFilterExtensionPtr関数。

166 ：デフォルトの名無しさん：2009/01/22(木) 00:19:29

皆さん如何されているかアイデアを聞かせてほしいんですが

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

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

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

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

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

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

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

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

167 ：デフォルトの名無しさん：2009/01/22(木) 00:26:50

暗号についての教科書でも読め

168 ：デフォルトの名無しさん：2009/01/22(木) 00:30:47

>>166
普通に非対称鍵暗号使えばいいんじゃ

169 ：デフォルトの名無しさん：2009/01/22(木) 00:32:48

共通鍵方式であれ公開鍵方式であれ鍵の扱い方は教科書には載ってない

170 ：166：2009/01/22(木) 00:40:06

>167-169

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

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

171 ：デフォルトの名無しさん：2009/01/22(木) 00:40:23

>>166
通信確立用のキーがクラックされることを考えるなら、
復号直後のデータを抜かれるクラックも想定が必要ということ?

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

172 ：166：2009/01/22(木) 00:44:55

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

173 ：デフォルトの名無しさん：2009/01/22(木) 00:50:25

通信の傍受は防げてもプログラムのクラックはいたちごっこだな

174 ：デフォルトの名無しさん：2009/01/22(木) 03:48:20

>>166
正規なクライアントだけが持っている情報は一切全く無い、と仮定
するけど、正規なクライアントだけ通信できるようにしたい、ってのは
原理的に不可能だと思う。

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

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

175 ：デフォルトの名無しさん：2009/01/22(木) 11:13:02

中間者攻撃というのがあってだな…。

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

176 ：175：2009/01/22(木) 11:14:40

思い出した。↑の方法でも中間者攻撃対策にはならないんだった。

177 ：デフォルトの名無しさん：2009/01/22(木) 11:25:02

正規のクライアントがクラックされてクローンを作られるのは防ぎようがないかな。

どうしても防ぎたければB-CASカードみたいな対タンパ性のあるハードウェアを
使うとか。

178 ：デフォルトの名無しさん：2009/01/22(木) 19:16:30

>>168
ここで答え出てるだろ。
クライアントでランダムな非対称鍵作って
暗号化用の鍵を相手に渡す。

179 ：デフォルトの名無しさん：2009/01/22(木) 21:43:51

MMOみたいな延滞厳禁な物に対して
暗号化を施すのも正直どうかと思うけどな

180 ：デフォルトの名無しさん：2009/01/22(木) 22:00:40

暗号化コストなんて送受信に比べたらカスみたいなもんだろ

181 ：デフォルトの名無しさん：2009/01/22(木) 23:33:12

共通鍵にしろ公開鍵にしろ
強度を高めようとしたら結構負荷がかかるぞ

そもそも暗号と高速化は相反する物だし

182 ：デフォルトの名無しさん：2009/01/23(金) 10:01:21

暗号化コストは結構でかいよ。
LANでギガビットイーサ+SSHだとネットの性能に暗号処理がおいつかない。

性能が必要ならストリーム暗号かね。

183 ：デフォルトの名無しさん：2009/01/23(金) 11:36:09

お前は一体何の話をしてるんだ

184 ：デフォルトの名無しさん：2009/01/23(金) 17:20:28

MMOでクライアントからサーバーに巨大なデータは送らない。

185 ：デフォルトの名無しさん：2009/01/24(土) 17:20:09

UDPの受信で到着順番が入れ替わる対応をするため
受信データにシーケンシャルなインデックスを入れて
受信時にソートするとする。

その場合、処理してしまったデータより前のデータが飛んできた時の処理って
仕様によるとは思うんだけど、どうするのがいいかな？
やっぱ捨てるの？

186 ：デフォルトの名無しさん：2009/01/24(土) 18:34:50

必要なら取り込む、不要なら捨てる

187 ：デフォルトの名無しさん：2009/01/25(日) 10:42:57

185が自分で言っているように仕様によるとしか言えない。

188 ：デフォルトの名無しさん：2009/01/25(日) 13:31:10

やっぱそうだよなー
でもせっかく届いたデータを捨てるのも勿体無い気がする・・・

設計自体を変えるしかなさそうだな。
色々試してみるお、ありがと。

189 ：デフォルトの名無しさん：2009/01/25(日) 13:38:41

そこを頑張り過ぎるといつのまにか劣化TCPを作るハメになるぞ

190 ：デフォルトの名無しさん：2009/01/25(日) 13:50:27

分散コンピューティング環境では思い切りが必要。

191 ：デフォルトの名無しさん：2009/01/25(日) 14:46:45

迷ったら、TCPを使わない理由を考えなしたほうがいい

192 ：デフォルトの名無しさん：2009/01/25(日) 22:02:47

意味判らんが
UDPの方がプログラマ寄りの考え方だぞ

193 ：デフォルトの名無しさん：2009/01/25(日) 22:24:03

それこそ意味がわからん。

194 ：デフォルトの名無しさん：2009/01/25(日) 22:27:12

プログラマ寄り？

195 ：デフォルトの名無しさん：2009/01/25(日) 22:51:09

まあ生パケットに近い (=プログラマの裁量範囲が大きい) と
言いたかったのではないかとエスパーしてみる。

196 ：デフォルトの名無しさん：2009/01/25(日) 23:08:06

じゃあアセンブラで書けよ。

197 ：デフォルトの名無しさん：2009/01/25(日) 23:30:12

また意味わからん奴が出てきたぞ

198 ：デフォルトの名無しさん：2009/01/26(月) 08:55:02

TCPとUDP、この２つで十分というのはおもしろいと思う

199 ：デフォルトの名無しさん：2009/01/26(月) 11:31:29

十分じゃないからその上の層にも下の層にもプロトコルがあるんだろうが。
tracerouteコマンドのように下の層を直接使うアプリもあるし。

200 ：デフォルトの名無しさん：2009/01/26(月) 20:28:26

ネットワークプログラミングに興味を持って始めてみようと思うのですが、
Windowsではwinsockが主流なのでしょうか？
長らく更新されていないようですけど、それだけ完成度が高いということですか？

201 ：デフォルトの名無しさん：2009/01/26(月) 21:30:45

うん

202 ：デフォルトの名無しさん：2009/01/26(月) 21:38:43

HTTPリクエストだけならWininetAPIの方が楽ちん

203 ：デフォルトの名無しさん：2009/01/26(月) 22:09:07

Winsock以外のプロトコルスタックの実装もあるにはあるけど、実際に使われてるのを
最近は見たことない。Winsockで十分だからね。

204 ：デフォルトの名無しさん：2009/01/26(月) 22:30:39

なんか意外な気もしますが普通に現役なんですね
取っ掛かりは簡単そうだし、少しやってみようと思います

205 ：デフォルトの名無しさん：2009/01/26(月) 22:34:01

ptrace(2)を使うのはほとんどのUNIXでお勧めではない。
詳しくはmanpageを読んでくれ。

206 ：デフォルトの名無しさん：2009/01/27(火) 03:58:49

ふつ～straceだよね

207 ：デフォルトの名無しさん：2009/01/27(火) 09:08:04

tracerouteは
UDPを投げてICMPの戻りを使うタイプのものと
ICMPを投げてICMPの戻りを使うものがある
この理解であってる？

208 ：デフォルトの名無しさん：2009/01/27(火) 14:05:03

あってる。

Linuxには-Iオプションとかもあるな。

209 ：デフォルトの名無しさん：2009/01/29(木) 23:21:46

ちょっと引くぐらいくだらない質問だと思いますが、教えてください。

TCPやUDPなどにはヘッダの構造が定義されていますが、
ポートからヘッダの構造に従ったパケットを送信しさえすれば
後はヘッダに定義したあて先にパケットが届くということでいいのでしょうか？

つまり、大雑把にいうとヘッダ構造にしたがってパケットを送信できれば
一応イーサネットの通信はできるという認識はあっているでしょうか。
（品質やエラー処理などは考慮しないとして）

210 ：デフォルトの名無しさん：2009/01/29(木) 23:45:01

そこいうポートって？

211 ：デフォルトの名無しさん：2009/01/29(木) 23:47:25

「で」が抜けた

212 ：デフォルトの名無しさん：2009/01/29(木) 23:49:15

あ、すいません。
書き方が悪かったです。

ここでのポートは、組込み開発のボード上にある
物理的なLANポートのことです。

213 ：デフォルトの名無しさん：2009/01/30(金) 00:01:21

>>209
恐らくネットワークの下層の存在を知らないんじゃないかな？　
TCP, UDP, IPまでは物理的な通信ハードウェアとは隔離されたレベルの
通信規格。　

その下層にあるデータリンク層がLANの場合ならIPアドレスから
イーサネットのアドレスへの変換、イーサネットヘッダーの追加、
イーサネットチェックサムの計算等をやってくれている。
ここの規格はネットワーク技術によって異なる。　他に
身近なものではwifiとかDSLで使われるPPPoEとか。

で、さらにその下の物理層が具体的な電気信号への変換を行う。

214 ：デフォルトの名無しさん：2009/01/30(金) 00:11:50

>>209
ファーム支援が何もない状態って事だよね？
ARPをちゃんと理解しないと、
イーサネット上でIPパケットを出すことは難しいよ。
ルーティングの知識もいる。

> その下層にあるデータリンク層がLANの場合なら

ルータの裏蓋程度の中途半端な知識で語るのやめれ

215 ：デフォルトの名無しさん：2009/01/30(金) 00:12:12

>>213
そういうことですか・・・少し理解が進みました。
ありがとうございます。

昨日からあるボードのイーサネットのソース解析を
行っているのですが、まったく知識がない状態で
解析しているので何が何だかわかっていないのです。

確かにソース上で、MACアドレスの取得（ARP？)を行ったり、
イーサネットヘッダの追加やチェックサムの計算を行っていました。

要はその部分がデータリンク層の実装ということですね。

ということは、データリンク層までを実装して
そのパケットをLANポートから送信してあげれば
イーサネット通信ができるということでいいでしょうか。

・・・もうソースを見ても何が何だかという感じです。
多少取っ掛かりはみえてきましたが。

216 ：デフォルトの名無しさん：2009/01/30(金) 00:16:08

>>214
そのファームの移植・・・という作業なのです。
（CPUが異なるボードへの移植です）

私はペーペーなので勉強も踏まえてという位置づけなのですが、
できるところまでやってみろという感じで
何とかやり遂げないとまずい状態にいます。

ちょっと憂鬱です。

217 ：デフォルトの名無しさん：2009/01/30(金) 00:20:12

>>3の本は読まないとね。

218 ：デフォルトの名無しさん：2009/01/30(金) 00:36:20

>>215-216
WireShark とかインストールして、ネットワーク上のパケット
見れば理解が少しはすすもかも。

どうせ、デバッグ段階でお世話になるだろうし。

219 ：デフォルトの名無しさん：2009/01/30(金) 00:37:35

移植するのに上位層から眺めてたら、わけわかめになるんじゃないの？

220 ：デフォルトの名無しさん：2009/01/30(金) 01:12:00

>>214
一応ルーターベンダでルータのコードいじってた。 IP, ルーティングが主専門だったが
時々データリンクもいじったし、ブートROMを新しいハードに移植もしたことある。

>>215
>ということは、データリンク層までを実装して
>そのパケットをLANポートから送信してあげれば

まだまだ。　データリンク層は下層の通信技術によって異なるが、これも
標準で定義された規格を実装しているハードウェア非依存のコード。　
コンパイルすればいいだけで「移植」は必要ないはず。　

移植が必要なのはその下のMAC層。　ここがイーサネットポートのチップと
実際にやりとりをする。

221 ：デフォルトの名無しさん：2009/01/30(金) 01:15:50

「データリンク層がLAN」とか良く言えるなw

222 ：デフォルトの名無しさん：2009/01/30(金) 01:19:58

>>220

223 ：213：2009/01/30(金) 02:55:55

>>221
かなり変だったね。　スマン。　単に「イーサネットのLANの場合、データリンク層は」と
言いたいのが言葉が絡まってしまった。
>>219
普通は最下層からも攻めますよね。　デバッグビルドでドライバの最下層の
ルーチンを独立に叩いてチップのレジスタを表示したり設定するデバッグコマンドを
いじりながらまずチップが叩ける様にするというのが常套手段でしょうか。

224 ：デフォルトの名無しさん：2009/01/30(金) 03:10:24

>>223
そういうやり方もありかと
あと、TCPで使うタイマーをどうするかぐらい？
ハードに依存した部分がソースで分離されてれば楽だろうね。
209は自分のMACアドレスとかどうするつもり何だろう？

225 ：デフォルトの名無しさん：2009/01/30(金) 22:07:47

>>218
今日はEtherealを使ってパケットのやり取りをみてみました（ARPだけですが）
確かに理解は進んで、イメージがつかめてきました。

>>219
・・・うーんそうですね。まだ解析方法自体へたくそなんだと思います。

>>220
BootROMを新しいハードに移植！
まさに今私がやらなければならない作業です。
初めての開発作業で、しかもファームの開発なので
デバッグもままなりません。やりがいはありますが・・・。

>移植が必要なのはその下のMAC層。
このキーワードが解析・移植作業のヒントになりそうです。
根元の部分のみ置き換えてやればいいんですね。
今日先輩にも同じようなことをいわれました。

>>224
いえ自分のMACアドレスというわけではなく、
ARPで宛先のMACアドレスを取得したかっただけです。

皆さん色々と助言をありがとうございます。

まだ来週からは、パケットの送受信をハードがどう行っているかの解析や
TCP/IPやらUDPやらその他もろもろの解析が続くので
苦労の日々は続きそうです。

また何かあれば相談させていただくかもしれませんが、
よろしくお願いします。

226 ：デフォルトの名無しさん：2009/01/30(金) 23:24:38

なぜいまさらEtherealなの？最新のWiresharkにしときなさい。

227 ：デフォルトの名無しさん：2009/01/31(土) 02:00:22

>まだ来週からは、パケットの送受信をハードがどう行っているかの解析や
>TCP/IPやらUDPやらその他もろもろの解析が続くので

そういうのは文献見りゃ分かるんだから解析とは言わない

228 ：779：2009/01/31(土) 12:40:14

WinSockでデスクトップイメージの通信を行っていますが、
クライアントの接続を切ったとたんに、サーバーが異常終了して
しまいます。原因がわかりませんか？

http://uproda11.2ch-library.com/src/11154199.zip.shtml

お願いします。

229 ：デフォルトの名無しさん：2009/01/31(土) 12:54:42

コードを流し見しただけだが
ソケット関係は入出力を含めてエラー処理が甘すぎ

230 ：デフォルトの名無しさん：2009/01/31(土) 13:13:07

何も見てないがWinSockのせいじゃないぞ

231 ：デフォルトの名無しさん：2009/02/01(日) 13:00:01

>>230
何のせいですか？

232 ：デフォルトの名無しさん：2009/02/01(日) 13:12:27

>>229-230
例外を処理していないのが原因だったようです。
ありがとうございました。

233 ：デフォルトの名無しさん：2009/02/01(日) 13:19:05

server側のFD_CLOSEにトラップしかけてトレースしたらすぐ分かるでしょ

234 ：デフォルトの名無しさん：2009/02/01(日) 16:26:44

>>228
Backdoor....ヒィーーーーッ、ガクガクブルブル

235 ：デフォルトの名無しさん：2009/02/01(日) 17:23:23

やべっ
落として実行しちゃったけどBackdoor仕掛けられちゃったか・・・

（

236 ：デフォルトの名無しさん：2009/02/01(日) 21:40:15

ご愁傷様です

237 ：デフォルトの名無しさん：2009/02/01(日) 21:51:01

落としてる途中で
怪しいと思ったので
放置してたんだけど
やっぱそうなん？

238 ：デフォルトの名無しさん：2009/02/01(日) 21:52:39

あっぶね
落したけど実効はしてない

239 ：デフォルトの名無しさん：2009/02/01(日) 22:20:37

UDPのソケットを作成してbind後に
どこかのアドレスにsendtoすると
selectでreadfdsが反応しちゃうんだけど
そゆもの？
なんで自分が受信可能になるの？

240 ：デフォルトの名無しさん：2009/02/01(日) 22:21:47

ちゃんとselect用のsocket分けてますか

241 ：デフォルトの名無しさん：2009/02/01(日) 22:48:30

ソケットは1つしか作成していません。
そのソケットをbindしてselectにセットしています。
さらにそのソケットでsendtoしてるんだけど、
それがまずいってことですか？

242 ：239：2009/02/01(日) 23:25:56

すいません、送信アドレスが127.0.0.でしたorz
申し訳ないです、忘れて下さい(´・ω・`)

243 ：デフォルトの名無しさん：2009/02/01(日) 23:58:27

｡゜（ﾟ´Д｀ﾟ）ﾉｳﾝｺ-

244 ：デフォルトの名無しさん：2009/02/02(月) 00:11:28

タヒぬ

245 ：デフォルトの名無しさん：2009/02/02(月) 02:12:56

>>228を落としてウィルススキャンして見たんだが反応しない
バックドアってどうしたら発見できるの？

246 ：デフォルトの名無しさん：2009/02/02(月) 03:04:46

作っているアプリの名前がbackdoor？

247 ：デフォルトの名無しさん：2009/02/02(月) 06:21:16

デスクトップイメージを送信している
それだけでbackdoorと言っても差し支えない

248 ：デフォルトの名無しさん：2009/02/03(火) 01:11:56

>すいません、送信アドレスが127.0.0.でしたorz
ﾜﾗﾀ

249 ：デフォルトの名無しさん：2009/02/03(火) 23:29:30

LinuxでIPアドレスが分かっているLAN内の他のホストのMACアドレスを知るプログラムを作りたいのですがどうすればいいですか？

できれば、他のプロセス（arpコマンドなど）は起動せず、
標準的な（apt-getせずにubuntuで使える）関数で簡単に数行で記述出来ると望ましいです。

250 ：デフォルトの名無しさん：2009/02/03(火) 23:34:48

なんでping→arp -aがだめなの？

251 ：デフォルトの名無しさん：2009/02/03(火) 23:53:07

ARPパケットの送信と受信がしたいのでは？

252 ：デフォルトの名無しさん：2009/02/04(水) 00:34:10

arp -a
一行

253 ：デフォルトの名無しさん：2009/02/04(水) 00:50:26

ttp://publib.boulder.ibm.com/infocenter/systems/index.jsp?topic=/com.ibm.aix.commtechref/doc/commtrf2/arpresolve_common.htm
ttp://publib.boulder.ibm.com/infocenter/systems/index.jsp?topic=/com.ibm.aix.commtechref/doc/commtrf2/arpupdate.htm

254 ：デフォルトの名無しさん：2009/02/04(水) 12:40:11

>>249
arpのソースをリンクすればいいんじゃないか？

255 ：デフォルトの名無しさん：2009/02/04(水) 13:27:29

>>254
ライセンス関連であまり悩みたくないので他のプログラムのソースを取り込むのは避けたいです。

できればarp()やget_remote_mac()のようなAPIがあれば嬉しいのですが。

256 ：デフォルトの名無しさん：2009/02/04(水) 13:29:23

>>253
ありがとうございます。参考にします。

257 ：デフォルトの名無しさん：2009/02/04(水) 13:30:26

>>250
他のプロセスを起動したくないからです。

258 ：デフォルトの名無しさん：2009/02/04(水) 13:40:19

注文が多いのう

259 ：デフォルトの名無しさん：2009/02/04(水) 16:18:33

>>255
つ　http://www.netlib.org/

260 ：デフォルトの名無しさん：2009/02/04(水) 16:20:51

>>259
あ、逆だった。　こっちだ orz
http://www.packetfactory.net/libnet/　

261 ：デフォルトの名無しさん：2009/02/04(水) 21:38:43

>>257
Linux前提なら /proc/net/arp 読めばいいんじゃね?
arpコマンドだってこれ読んでるだけだよ。

キャッシュにないときの処理は後自分で考えるんだぞ。

262 ：デフォルトの名無しさん：2009/02/04(水) 21:49:06

キャッシュについては
ていうかpingも自分で実装？

263 ：デフォルトの名無しさん：2009/02/04(水) 23:54:13

>>260
ありがとうございます。
やっぱり標準装備のライブラリじゃできないですかね。。
導入するならこれかlibpcapかな。

264 ：デフォルトの名無しさん：2009/02/04(水) 23:55:38

>>262
いや、接続しようとするだけで問題なし。
出来なくてもARPは行われるから。

265 ：デフォルトの名無しさん：2009/02/04(水) 23:56:02

>>261
ありがとうございます。
確かにそれはいいアイディアですね。
テキスト処理が若干面倒ですが。

266 ：デフォルトの名無しさん：2009/02/04(水) 23:57:50

>>262
御存じのこととは思いますが、pingとarpキャッシュは直接関係ありませんよ。
pingがアドレス解決するのでその副作用でarpキャッシュが更新されるだけです。

267 ：デフォルトの名無しさん：2009/02/05(木) 17:34:42

>>264
確かにそれはいいアイディアですね。
自分でARP投げるのも出来ませんかね。

268 ：デフォルトの名無しさん：2009/02/05(木) 18:11:46

ttp://www.itbook.info/study/arp3.html

269 ：デフォルトの名無しさん：2009/02/05(木) 21:37:23

https://arco.esi.uclm.es/svn/public/misc/scapy/arping.py

270 ：デフォルトの名無しさん：2009/02/05(木) 22:45:25

ttp://www.secdev.org/projects/scapy/
ttp://www.secdev.org/projects/scapy/demo.html

271 ：デフォルトの名無しさん：2009/02/05(木) 22:45:39

>>267
こっちが聴きたい。「あなたは実装できないのですか？」

272 ：デフォルトの名無しさん：2009/02/05(木) 22:47:14

http://www.designandcommunication.co.jp/Python/packet.html

273 ：デフォルトの名無しさん：2009/02/05(木) 22:49:29

>>271
Cでは出来るけど >>249 の言うような

>できれば、他のプロセス（arpコマンドなど）は起動せず、
>標準的な（apt-getせずにubuntuで使える）関数で簡単に数行で記述出来ると望ましいです。

「標準的な関数で簡単に数行で」って言われると
自分の関数リンクするのもアウトだろうから
arp -a 以外に思いつかない

274 ：デフォルトの名無しさん：2009/02/05(木) 22:55:44

http://ilab.cs.byu.edu/python/
http://heather.cs.ucdavis.edu/~matloff/Python/PyNet.pdf
http://www.amazon.co.jp/Foundations-Python-Network-Programming/dp/1590593715
http://d.hatena.ne.jp/rintaromasuda/20060521/1148167342
http://www.onlamp.com/pub/a/python/2006/08/10/untwisting-python-network-programming.html
http://simonwillison.net/2004/Feb/18/advanced/

275 ：デフォルトの名無しさん：2009/02/05(木) 23:27:45

under Linux only
import sys
import string
import struct
from socket import *

proto = 0x55aa
s = socket(AF_PACKET, SOCK_RAW, proto)
s.bind(('eth1', proto))
ifName, ifProto, pktType, hwType, hwAddr = s.getsockname()
srcAddr = hwAddr
dstAddr = '\x01\x02\x03\x04\x05\x06'
ethData = 'here is some data for an ethernet packet'
txFrame = struct.pack('!6s6sh', dstAddr, srcAddr, proto) + ethData
print 'Tx[%d]: ' % len(ethData) + string.join(['%02x' % ord(b) for b in ethData], ' ')
s.send(txFrame)
rxFrame = s.recv(2048)
dstAddr, srcAddr, proto = struct.unpack('!6s6sh', rxFrame[:14])
ethData = rxFrame[14:]
print 'Rx[%d]: ' % len(ethData) + string.join(['%02x' % ord(b) for b in ethData], ' ')
s.close()

276 ：デフォルトの名無しさん：2009/02/05(木) 23:31:13

なんとか出来そうです
ありがとうございました

277 ：249 ◆ZHAPRHY6Ag ：2009/02/06(金) 00:13:24

話の流れが分からなくなりつつあるので名前を付けます。

ちなみに私の書き込みは下記のレスです。

>>249 >>255-257 >>263 >>265-266

278 ：249 ◆ZHAPRHY6Ag ：2009/02/06(金) 00:27:48

大切なことを言い忘れていましたが、CかC++で実装したいと考えています。

それと、あくまでも同一LAN内のMACアドレスが分かっているリモートホストのIPアドレスが知りたいのであって
明示的にARPリクエストを送りたいわけではありません。したいのはあくまでもIPアドレスを取得することです。

RAWソケットを開いたりする必要こと無く、標準関数あるいは標準機能と数行の記述でIPアドレスを取得できることが希望です。
標準関数を希望するのは、OSに標準的に付属する以外にソフトウェアを取得するのは、権利の関係が面倒なので避けたいからです。

例えば、標準関数でint get_mac_address(struct arpreq *req) のような関数があると理想的です。

279 ：デフォルトの名無しさん：2009/02/06(金) 00:35:16

もうとっくに書き終わったかと思ったよw

280 ：デフォルトの名無しさん：2009/02/06(金) 00:38:57

>>249
IPアドレスが分かっているLAN内の他のホストのMACアドレスを知る
>>278
MACアドレスが分かっているリモートホストのIPアドレスが知りたい

謎ですなあ。

281 ：デフォルトの名無しさん：2009/02/06(金) 01:41:03

int get_mac_address(struct arpreq *req)
じゃなくて
int get_ip_address(struct mac_addr *mac)
だよなぁ
謎

282 ：249 ◆ZHAPRHY6Ag ：2009/02/06(金) 01:57:16

ああそうですね。間違えました。求めるたいのはIPアドレスです。

○例えば、標準関数でint get_ip_address(struct arpreq *req) のような関数があると理想的です。

283 ：249 ◆ZHAPRHY6Ag ：2009/02/06(金) 02:00:25

>>280 >>281
ああちがいました。
求めたいのはMACアドレスです。

ですので、
○例えば、標準関数でint get_mac_address(struct arpreq *req) のような関数があると理想的です。

284 ：249 ◆ZHAPRHY6Ag ：2009/02/06(金) 02:02:28

（>>278は間違いなので書きなおします。）

大切なことを言い忘れていましたが、CかC++で実装したいと考えています。

それと、あくまでも同一LAN内のIPアドレスが分かっているリモートホストのMACアドレスが知りたいのであって
明示的にARPリクエストを送りたいわけではありません。したいのはあくまでもMACアドレスを取得することです。

RAWソケットを開いたりする必要こと無く、標準関数あるいは標準機能と数行の記述でMACアドレスを取得できることが希望です。
標準関数を希望するのは、OSに標準的に付属する以外にソフトウェアを取得するのは、権利の関係が面倒なので避けたいからです。

例えば、標準関数でint get_mac_address(struct arpreq *req) のような関数があると理想的です。

285 ：デフォルトの名無しさん：2009/02/06(金) 02:03:01

>>278
> 標準関数でint get_mac_address(struct arpreq *req) のような関数があると理想的です

今までの流れでそんなのは無いというのが分からんのか？　今までのレスで十分その
関数を自分で書くだけの情報はあるはずだぞ。　

286 ：249 ◆ZHAPRHY6Ag ：2009/02/06(金) 02:12:48

無いのですね。わかりました。ありがとうございました。

ちなみに、macアドレスを取得する関数はRAWソケットで既に作りました。
マルチプラットフォームでの移植性を考えるとlibpcapを使った方がよさそうでしたけど、移植することもないのでこちらにしました。

標準関数で同機能があればそちらで作り直したかったのですが仕方ありませんね。

287 ：デフォルトの名無しさん：2009/02/06(金) 03:21:05

http://pc11.2ch.net/test/read.cgi/tech/1232455653/
ここでマルチしてんのか

288 ：デフォルトの名無しさん：2009/02/06(金) 08:20:08

何がマルチ？

289 ：デフォルトの名無しさん：2009/02/06(金) 08:44:00

>>282-283
指摘されているにも関わらず同じ間違いを繰り返してしまうキミは
プログラミングを止めた方がいい。経験上。

290 ：デフォルトの名無しさん：2009/02/06(金) 09:15:51

同じじゃないですよ？

291 ：デフォルトの名無しさん：2009/02/06(金) 09:17:48

愚者は経験に従うとも言います。

292 ：デフォルトの名無しさん：2009/02/06(金) 10:29:01

神だって何度も間違える。

293 ：デフォルトの名無しさん：2009/02/06(金) 10:32:30

プログラマは2度間違えない。

294 ：デフォルトの名無しさん：2009/02/06(金) 11:11:28

人間は何度でも間違える。

295 ：デフォルトの名無しさん：2009/02/06(金) 11:33:57

プログラマは2度間違えない。

296 ：デフォルトの名無しさん：2009/02/06(金) 13:21:01

プログラマーって最高ですね。

297 ：デフォルトの名無しさん：2009/02/06(金) 15:16:43

おばあちゃんが執事にするならプログラマが一番だって。

298 ：デフォルトの名無しさん：2009/02/06(金) 15:22:32

>>284
ここにいる奴に書かせるつもりだなw

299 ：デフォルトの名無しさん：2009/02/06(金) 16:19:25

ブロードキャストのパケット監視するとか？

300 ：デフォルトの名無しさん：2009/02/06(金) 16:30:03

そうそう/proc/net/arpをずーと監視してればいつかは…
っておい！

301 ：デフォルトの名無しさん：2009/02/06(金) 21:08:50

過疎

302 ：デフォルトの名無しさん：2009/02/06(金) 21:18:49

↑過疎の原因

303 ：デフォルトの名無しさん：2009/02/06(金) 22:22:51

蘇我入鹿

304 ：デフォルトの名無しさん：2009/02/07(土) 01:18:21

金玉かゆい

305 ：デフォルトの名無しさん：2009/02/07(土) 01:34:59

なるほど
ありがとうございました

306 ：デフォルトの名無しさん：2009/02/07(土) 03:05:56

ProxyARP

307 ：デフォルトの名無しさん：2009/02/07(土) 03:13:40

ttp://www.geocities.jp/ptrs_sec/ipcat/

308 ：デフォルトの名無しさん：2009/02/07(土) 12:17:31

パケットキャプチャについて質問なんです
自身のローカルIPにbindしてプロミスキャスモードに設定するとパケットキャプチャができますが、特定のIPとのパケット通信のみをキャプチャするにはどうすればいいんでしょうか？
全部とって選別よりも、それ以外取得できないようにしたほうが軽いと思うんです
試しにその特定のIPにbindしてプロミスキャスモードに設定しようとしたらエラーが出ました

309 ：デフォルトの名無しさん：2009/02/07(土) 12:41:32

ドライバが対応していればその機能を使う。
対応していないなら、そういうドライバを作る。

310 ：デフォルトの名無しさん：2009/02/07(土) 14:18:21

複雑だと思うならつかわなきゃいいんじゃねーの？
なんでアホはあるもの全部使わなきゃ気がすまねーの？

311 ：デフォルトの名無しさん：2009/02/07(土) 14:23:11

どっちにしろ対象を絞り込むときに選別しなきゃならんわけで

312 ：デフォルトの名無しさん：2009/02/07(土) 14:44:47

このスレって俺を含めてド素人しかいない予感ｗ

313 ：デフォルトの名無しさん：2009/02/07(土) 15:22:25

同じフィルタリングでも、カーネルモードとユーザランドでは性能が段違い。

314 ：デフォルトの名無しさん：2009/02/07(土) 15:22:28

素人さん向け
ttp://www.tef-room.net/tool/PromiScan.html
ttp://www.space-peace.com/ethereal/check/ethereal_check_4.htm

315 ：デフォルトの名無しさん：2009/02/07(土) 19:10:19

俺もド素人ｗ

316 ：デフォルトの名無しさん：2009/02/07(土) 19:11:12

TCPソケットでconnectすると
接続元アドレスが自動で設定されると思うんだけど
複数IPアドレスがあった場合どうなるの？

317 ：デフォルトの名無しさん：2009/02/07(土) 19:33:02

bind

318 ：デフォルトの名無しさん：2009/02/07(土) 19:57:20

なるほど
ありがとうございました

319 ：デフォルトの名無しさん：2009/02/07(土) 20:10:45

処理するのにbindすればいいのは分かるんだけど
bindしないでconnectした時のアドレス割り当てが
どういったルールになってるのかなって。

320 ：デフォルトの名無しさん：2009/02/07(土) 20:35:40

普通はそのインターフェースのプライマリアドレス

321 ：デフォルトの名無しさん：2009/02/07(土) 21:24:44

>>320
ちゃんとプライマリとか見てくれるのか
ありがとー

322 ：デフォルトの名無しさん：2009/02/08(日) 06:32:35

何でこの板IDないの？

323 ：デフォルトの名無しさん：2009/02/08(日) 07:49:43

紳士だからさ

324 ：デフォルトの名無しさん：2009/02/08(日) 09:44:13

変態という名の紳士

325 ：デフォルトの名無しさん：2009/02/08(日) 22:47:12

地震キタ

326 ：デフォルトの名無しさん：2009/02/09(月) 01:07:46

thread_Aにてepoll_wait中に、thread_Bからepoll_ctlで監視対象fdを操作(EPOLL_CTL_DELとか)しても、
即座にthread_Aで止まってるepoll_waitは反映してくれない？

というか、epoll_fdに対しての非同期操作は自分で排他処理しないとダメ？

327 ：デフォルトの名無しさん：2009/02/10(火) 10:50:58

>>320
まともなOSならそんなことしない。
インターフェイスへの複数アドレス付与を、付け焼刃で実装したOSならあるかもしれんけど。

>>321
そのホストのルーティングテーブルを参照して、接続先アドレスに到達可能な最小コストのルートを選択して、
接続元とするアドレスが決められる。
インターフェイスAに、10.0.0.1/24と、192.168.0.1/24が振られてて10.0.0.1がプライマリだったとしても、
192.168.0.2に接続するときには、192.168.0.1がsourceとして使われる。

328 ：デフォルトの名無しさん：2009/02/10(火) 11:25:55

んー
同じセグメントのIPが複数振られてたらどっちが使われる？

329 ：デフォルトの名無しさん：2009/02/10(火) 11:26:06

プログラム言語はなぜ「言語」と呼ばれるのでしょう？
通常使っている言語とどのような共通点があるか？
またどのような相違点があるか？

という問題を誰か教えてくれませんか?

330 ：デフォルトの名無しさん：2009/02/10(火) 11:40:40

>>329
ウィキペれ。

331 ：デフォルトの名無しさん：2009/02/10(火) 11:43:37

ウィキにのってないポ（;・∀・）

332 ：デフォルトの名無しさん：2009/02/10(火) 11:45:36

>>328
>>327に書いてあるでしょ。

333 ：デフォルトの名無しさん：2009/02/10(火) 13:56:50

>>332
同じインタフェースに 192.168.0.1/24 と 192.168.0.2/24 が振られているときに
192.168.0.254 に接続したらどうなるか、って話でしょ。>>327には書いてないと思うが。

Linuxの場合、ソースをチラ見しただけだがプライマリを使うようになってる
っぽいな。明確な仕様なのかはよく知らないけど。

334 ：デフォルトの名無しさん：2009/02/10(火) 22:47:46

質問です。

UDPソケットでrecvした時に複数のパケットがくっついて読み込まれる事ってありえますか？

335 ：デフォルトの名無しさん：2009/02/10(火) 22:53:52

あり得ません。

336 ：デフォルトの名無しさん：2009/02/10(火) 23:00:45

>>335
ありがとうございました

337 ：デフォルトの名無しさん：2009/02/10(火) 23:01:28

おい、誰の発言かわからん一言を、そんなに簡単に信じちゃうのかよ。

338 ：デフォルトの名無しさん：2009/02/10(火) 23:18:03

>>337

339 ：デフォルトの名無しさん：2009/02/10(火) 23:27:58

本当はどうなんでしょうか？

340 ：デフォルトの名無しさん：2009/02/10(火) 23:32:09

わかりません

341 ：デフォルトの名無しさん：2009/02/10(火) 23:36:14

>>339 RFC 読めばええんちゃう？

342 ：デフォルトの名無しさん：2009/02/11(水) 00:01:12

普通にありえる。

343 ：デフォルトの名無しさん：2009/02/11(水) 00:08:08

OSのバグみたいな、よっぽどのことがない限りないでそ。

344 ：デフォルトの名無しさん：2009/02/11(水) 00:08:56

OSと何の関係が

345 ：デフォルトの名無しさん：2009/02/11(水) 00:12:19

UDPソケットって何?

346 ：デフォルトの名無しさん：2009/02/11(水) 00:17:01

そう来ますか

347 ：デフォルトの名無しさん：2009/02/11(水) 00:21:59

343じゃないが、
>>334は「recv」と書いており、これはOSのAPIと理解できる。
UDPのRFCでは、OSのAPIの事は、

User Interface
--------------
A user interface should allow

the creation of new receive ports,

receive operations on the receive ports that return the data octets
and an indication of source port and source address,

and an operation that allows a datagram to be sent, specifying the
data, source and destination ports and addresses to be sent.

しか規定しておらず、複数のパケットを一つにまとめてrecvするOSがあってもよい。
ただし実際そういうAPIを持つOSはいまだかつて見たことがないが。

以上のことはRFCを読んだことがある人間には常識なので、
>>344は読んだことがないのだろう。

上に書いたような意味において、>>334への返答は「あり得ません。」
この返答で正しい。

348 ：デフォルトの名無しさん：2009/02/11(水) 00:22:18

IEEE Std 1003.1, 2004

recvのDescriptionから
＞For message-based sockets, such as SOCK_DGRAM and SOCK_SEQPACKET,
＞the entire message shall be read in a single operation.

349 ：デフォルトの名無しさん：2009/02/11(水) 00:27:18

で、このshallはもちろん仕様書に良くある強制のshallなので、
パケットを纏めてしまうと、すくなくとも、POSIXは満たさなくなる。

>shall
>For an implementation that conforms to IEEE Std 1003.1-2001,
>describes a feature or behavior that is mandatory.
>An application can rely on the existence of the feature or behavior.

350 ：デフォルトの名無しさん：2009/02/11(水) 00:27:19

最初から書いとけ馬鹿

351 ：デフォルトの名無しさん：2009/02/11(水) 01:29:43

みなさん、ありがとうございました

352 ：デフォルトの名無しさん：2009/02/11(水) 03:41:46

何に対して礼を言っているのだ

353 ：デフォルトの名無しさん：2009/02/11(水) 03:42:37

始めてみようかと思うんですが。
まずなにからすればいいんでしょうか？
ダイアログにWebBrowserコントロールを張り付ければいいんですか？

354 ：デフォルトの名無しさん：2009/02/11(水) 03:43:12

>>352
みなさん　ではないんでしょうか？

355 ：デフォルトの名無しさん：2009/02/11(水) 10:16:31

>>353
スレ違い。

356 ：デフォルトの名無しさん：2009/02/11(水) 10:38:13

>>347-349
力抜けよ

357 ：デフォルトの名無しさん：2009/02/11(水) 11:20:27

アッー！

358 ：デフォルトの名無しさん：2009/02/11(水) 17:23:26

なんだこの流れは…たまげたなぁ

359 ：デフォルトの名無しさん：2009/02/11(水) 21:00:32

>>353 はもっと評価されていい。

>始めてみようかと思うんですが。
何をだ！？と思った次の瞬間、

>まずなにからすればいいんでしょうか？
いや知らんがなー！と突っ込まずにはいられない。

360 ：デフォルトの名無しさん：2009/02/12(木) 01:38:36

神との対話を見た

361 ：デフォルトの名無しさん：2009/02/12(木) 09:32:53

どこに書けばいいのかわからないので、お手数ですが。
Rubyで書いた、ウェブページとそこのリンク先を取り込むスクリプトを
動かしていたら途中でconnect refusedになって以後つながりません。
"www.linux.org"だったんですけど、他では問題ありません。
図書館でやっても途中で切れました。
某図書館では"www.linux.org"につながらなくなっているかもしれませんゴメンナサイ。
いったいどうゆうことなんでしょうか。
なにが気に入らなかったんでしょうか。
まる二日たちますが、接続拒否は解除されるんでしょうか。

362 ：デフォルトの名無しさん：2009/02/12(木) 10:45:59

>>361
一度に多接続すると制限されることはあるね。
どれくらいの期間制限されるかはサイトのポリシーだから一概には言えないね。

363 ：デフォルトの名無しさん：2009/02/12(木) 13:50:33

接続拒否されるってどんなスクリプト流したんだよ・・・

364 ：デフォルトの名無しさん：2009/02/12(木) 14:25:13

既存サイトを攻撃してはいけません

365 ：デフォルトの名無しさん：2009/02/12(木) 15:22:03

一度でも攻撃受けたとこはこの辺厳しい

366 ：デフォルトの名無しさん：2009/02/12(木) 15:26:12

なんて迷惑な奴

367 ：デフォルトの名無しさん：2009/02/12(木) 19:14:35

お約束ですが
通報しました

368 ：デフォルトの名無しさん：2009/02/12(木) 20:17:07

http://www.itmedia.co.jp/news/articles/0902/12/news091.html

369 ：デフォルトの名無しさん：2009/02/12(木) 20:20:41

IPアドレスを取得まではできたのですが、
取得したIPアドレスを利用して「ping」をうちたいのですが
どうしたらpingをうつプログラム書けますか？
手順を教えてください（ex　関数などを）

370 ：デフォルトの名無しさん：2009/02/12(木) 20:29:12

使ってる言語くらい書け。

371 ：デフォルトの名無しさん：2009/02/12(木) 20:50:31

Ｃ言語です。

372 ：デフォルトの名無しさん：2009/02/12(木) 22:04:37

ping()

373 ：デフォルトの名無しさん：2009/02/12(木) 22:20:59

なんで途中までは出来た、みたいな言い方になってんだ

374 ：デフォルトの名無しさん：2009/02/12(木) 22:57:05

>>369 ping したいんだけだたら system("ping ...")

375 ：デフォルトの名無しさん：2009/02/12(木) 23:26:29

おまいら、理解力の無い俺に救いの手を・・・

ルータ越しにサーバーとクライアントのプログラムを走らせるとして、
サーバーをSourcePort10000で立ち上げる。
クライアントをSourcePort5000、DestinationPort10000でサーバーに接続する。

この場合、サーバー側のポート10000を空けないと接続できないんだけど、
クライアント側はポートを空けなくても送受信できちゃいます。
なんでなの？(´・ω・`)

376 ：デフォルトの名無しさん：2009/02/12(木) 23:29:40

インバウンドしかブロックしないファイアーウォールなんだろ

377 ：デフォルトの名無しさん：2009/02/12(木) 23:33:44

>>375
> サーバーをSourcePort10000で立ち上げる。

SourcePort→AcceptPort

378 ：デフォルトの名無しさん：2009/02/12(木) 23:37:00

>>376
クライアントは受信もできちゃうんだけど
そゆものなの？(´・ω・`)

>>377
AcceptPortだったか
ありがとうございます。

379 ：デフォルトの名無しさん：2009/02/12(木) 23:57:36

>>378
そゆものでしょ

380 ：デフォルトの名無しさん：2009/02/13(金) 01:01:06

>>379
そんなのいやだぁぁぁ
ちゃんと理解したいぃぃぃ

なんでポート開いてないのに受信できるの！

( ﾟдﾟ)＜誰かぁぁぁぁ

381 ：デフォルトの名無しさん：2009/02/13(金) 01:18:21

>>380
ファイアーウォールは外向きのパケットが通るとその発信元ポート、アドレス、
及び通信先ポート、アドレスの４組の情報を「セッション」として覚える。
パケットが帰って来るとそのセッションに当てはめ、一致するセッションがあれば
通してあげる。

382 ：デフォルトの名無しさん：2009/02/13(金) 01:32:24

SPI

383 ：デフォルトの名無しさん：2009/02/13(金) 01:39:11

>>381
おー、そうなのですか
だからサーバーはポート開けないとダメなのかー
理解できますた。
分かりやすい解説ありがとうございましたヽ(´ー｀)ノ

>>382
SPIググってみました。
Stateful Packet Inspection
これか、これなのか！
勉強になりますたヽ(´ー｀)ノ

384 ：デフォルトの名無しさん：2009/02/13(金) 15:31:17

ヽ(´ー｀)ノヽ(´ー｀)ノヽ(´ー｀)ノヽ(´ー｀)ノヽ(´ー｀)ノ

385 ：デフォルトの名無しさん：2009/02/13(金) 20:54:37

無免許でのネットワークプログラミングは処罰の対象ですよ。

386 ：デフォルトの名無しさん：2009/02/13(金) 20:57:16

また大阪か

387 ：デフォルトの名無しさん：2009/02/13(金) 21:38:50

ネットワーク従事者の許認可は逓信省電波管理局の管轄です

388 ：デフォルトの名無しさん：2009/02/14(土) 10:16:09

免許は逓信大臣が交付じゃね？

389 ：デフォルトの名無しさん：2009/02/14(土) 10:28:44

情報処理技術者試験 (ネットワーク) は、橋本龍太郎通産大臣 (当時) だったな。

390 ：デフォルトの名無しさん：2009/02/14(土) 23:35:59

高負荷になるとrecvがECONNRESETを返すようになってしまいます。
なにか心当たりがある方いらっしゃいますか？

391 ：デフォルトの名無しさん：2009/02/14(土) 23:38:14

>>390
リモートのホストに聞いてください。

392 ：デフォルトの名無しさん：2009/02/14(土) 23:41:18

「おらくたびれただよ、ちょっと休ませてくれかの？」

393 ：デフォルトの名無しさん：2009/02/15(日) 00:50:10

>>391

リモートのホストもこちらの制御下なのですが。。

394 ：デフォルトの名無しさん：2009/02/15(日) 00:50:39

じゃあ聞けよ。

395 ：デフォルトの名無しさん：2009/02/15(日) 00:50:59

どうやって制御してるの？

396 ：デフォルトの名無しさん：2009/02/15(日) 01:21:34

>>395
リモートのホストに聞いてください。

397 ：デフォルトの名無しさん：2009/02/15(日) 01:23:55

>>396
ちがう。

リモートのホストが>>393の制御下にあるというから、
どうやって制御しているのかを聞いている。

398 ：デフォルトの名無しさん：2009/02/15(日) 10:39:33

いろいろ説明不足ですいません。。

クライアントでrecvするとECONNRESETが返ってきます。
サーバ側でアクティブ・クローズしてるのですが、これが原因なんですかね？
処理の流れとしては、以下のような感じになっています。

client　　　　server
　　　　　　　accept
connect
send
　　　　　　　recv
　　　　　　　send
recv　　　　　close (クライアントのrecvとサーバのcloseとのタイミングが問題？）
close

よく考えると、サーバ側でsendしても実際は送られてない可能性が高いので、
その後すぐcloseしてしまうのは、問題な気もしますが、
高負荷でないとこの方法でうまく行きます。
（うまく行ってる場合は、たまたまsendがすぐにデータを転送していたということでしょうか？）
サーバ側では、sendしたあと、peerがcloseしたのを確認した後にcloseするのが
いいのでしょうか？
（recvで0が返ってくるまでcloseしないとか）

どなたかご教授ください

399 ：デフォルトの名無しさん：2009/02/15(日) 11:00:24

>>398
> （recvで0が返ってくるまでcloseしないとか）

& shutdown

400 ：デフォルトの名無しさん：2009/02/15(日) 11:00:38

>>398
最後サーバからなにsendしてるのかしらんけど
双方のパケットの内容はモニターしてチェックしたの？
してないんだったらまずはそっからじゃね？

401 ：デフォルトの名無しさん：2009/02/15(日) 11:00:44

>>398
http://www.kt.rim.or.jp/~ksk/wskfaq-ja/newbie.html#howclose

402 ：デフォルトの名無しさん：2009/02/15(日) 11:45:12

>>399,401
ありがとうございます。

1. データ送信を完了する。
2. shutdown()をhowパラメータを 1 に設定して呼び出す。
3. recv()が 0 を返却するまでループする。
4. closesocket()を呼び出す。

1の「送信を完了する」というのは、実際に送信が完了したかの確認ではなく、
send(write)を呼んでstatusがOKかを確認するということでいいんですかね？

とりあえず、試してみます。

403 ：デフォルトの名無しさん：2009/02/15(日) 11:57:05

そだね、最後にちゃんとFINの立ったTCPセグメントを送ってやるって事。
recv側はちゃんとFINの立ったTCPセグメントを食ってやるって事。
それでどちら側もちゃんとshutdownできる。
何も難しいことはやってない。

404 ：デフォルトの名無しさん：2009/02/16(月) 19:23:21

非同期ソケットでFD_READの通知がきたとき
int ret = recv(socket , buf , 128 , 0 );//whileループは使わない。
ret == -1はあるきがするのですが(ブロッキングなど)
ret == 0はあるのでしょうか？
ブロッキングソケットの場合はrecvでとまっているので ret == 0で切断などであるとは思うのですが。

405 ：デフォルトの名無しさん：2009/02/17(火) 02:39:11

マニュアルにないと書いてなければあると思わなければいけない。

406 ：デフォルトの名無しさん：2009/02/17(火) 10:35:44

>>361ですが、やっとこ、つながりました。一週間でしたね。
サーバー管理している皆様
セキュリティは、ほどほどにお願いします。

407 ：デフォルトの名無しさん：2009/02/17(火) 10:38:02

お前氏んでいいよ

408 ：デフォルトの名無しさん：2009/02/17(火) 12:21:38

>>407
おまえの母ちゃんよりマシ。

409 ：デフォルトの名無しさん：2009/02/17(火) 12:39:25

サーバー管理者から害のあるスクリプトと認定されるものを走らせてアク禁くらって
まるでサーバー管理者側が悪いかのような口のきき方すれば
罵声を浴びるに決まってるだろ

人のことをとやかく言う前にまず自分のスキルを上げろって話さ

410 ：デフォルトの名無しさん：2009/02/17(火) 14:13:00

>>409
あっそ

411 ：デフォルトの名無しさん：2009/02/17(火) 14:58:21

>>410
うん
そういうこと

412 ：デフォルトの名無しさん：2009/02/17(火) 15:01:41

まあ普通にサーバ管理者に問い合わせれば済む話だしな。

413 ：デフォルトの名無しさん：2009/02/17(火) 18:00:16

一応書いておきますが、406と408、410は、別人です。
わたしは、どのみちシロウトです。

414 ：デフォルトの名無しさん：2009/02/17(火) 18:38:28

>>413の付け足しですが。
>>406は、ただ最後にちょっと気の利いたことを書いておこうと
思っただけです。
気に障ったらすみません。
でもネットには、けんかを買いたい人が待ち構えてるんだね。
>>408には、笑った。

415 ：デフォルトの名無しさん：2009/02/17(火) 19:40:55

ネットにはよそのサイトをDoSしても開き直っている奴いるしね。

416 ：デフォルトの名無しさん：2009/02/17(火) 20:31:15

もうやめて！>>361 のHPは０よ！

417 ：デフォルトの名無しさん：2009/02/17(火) 20:58:07

HPが0なら死ねよ

418 ：デフォルトの名無しさん：2009/02/17(火) 22:49:16

おまいら、また理解できないことが出てきちゃいました・・・

acceptで取得したソケットにはSourceAddressとPortが設定されています。
これはサーバーのAcceptAddressとPortです。
さらにacceptで取得したソケットにも同じアドレスがbindされています。

通常、複数のソケットに同じアドレスをbindする事はできないと思うのですが
なんでacceptはできるの？

プログラムで同じように複数のソケットに同じアドレスを
bindすることは可能なのですか？

正直使いたくてうらやましいです(´・ω・`)

419 ：デフォルトの名無しさん：2009/02/17(火) 23:01:40

同時じゃないんだからできるだろ

420 ：デフォルトの名無しさん：2009/02/17(火) 23:02:21

>>418
> 複数のソケットに同じアドレスをbind

されてはいないだろ。

> acceptで取得したソケット

はacceptしてるソケットとは別なんだから。

# TCPの接続は<srcIP, srcPort, dstIP, dstPort>の四つ組みで識別される。

421 ：デフォルトの名無しさん：2009/02/17(火) 23:12:26

>>419
すいません、何が同時じゃないんですか？(´・ω・`)

>>420
acceptで取得したソケットをbindしようとするとEINVALが返ってくるんだけど、
これはbindされてるって事じゃないんですか？(´・ω・`)

422 ：デフォルトの名無しさん：2009/02/17(火) 23:15:06

まじめに質問してるのであれば、顔文字やめろ
腹が立つ

423 ：デフォルトの名無しさん：2009/02/17(火) 23:17:58

>acceptで取得したソケットをbindしようとすると

んん？

424 ：デフォルトの名無しさん：2009/02/17(火) 23:29:31

>>422
すいません、マジメに質問してるので顔文字はやめます。

>>423
試しにやってみただけなんですけどEINVALが返ってきました。

bindされていると思った理由は
取得したソケットからgetsocknameでアドレスが取れるので
bindされてるのかなと思いました。

425 ：デフォルトの名無しさん：2009/02/17(火) 23:33:36

acceptに返された時点で「TCP接続」とbindされてる。

426 ：デフォルトの名無しさん：2009/02/17(火) 23:47:22

別に顔文字使ってもいいよ。真面目かどうかは内容で分かるから。
顔文字の有無で内容が変わって見えるような馬鹿なんかに初めから回答を期待しない方がいい。

427 ：デフォルトの名無しさん：2009/02/17(火) 23:54:31

>>424
TCP の 3way handshake を調べて、各 phase で何が渡されるか考えるのが吉

428 ：デフォルトの名無しさん：2009/02/17(火) 23:55:52

acceptで生成されたソケットのポートはリスナーのポートじゃねーだろ？

429 ：デフォルトの名無しさん：2009/02/17(火) 23:56:25

顔文字で判断なんて、ココロが広いな
「おまいら」などと言ってる時点で無視だよ

430 ：デフォルトの名無しさん：2009/02/18(水) 00:05:28

>>425
そのbindされたアドレスが他のソケットとかぶってるってことなんだけど
これはシステム上、srcAddressとPortがかぶるソケットがあっても
問題ないと自分は解釈したんだけど
accept以外にプログラムで同じことできないかなと思いました。

>>426
2chで顔文字怒られたのは初めてでした。
不快に思う人も居るって事で。

>>427
どうもです。
3way hand shake調べなおしてみます。

>>428
srcPortはリスナーのポートだと思います。

>>429
ごめんなさい。

431 ：デフォルトの名無しさん：2009/02/18(水) 00:31:36

(´・ω・`)おこんなよ
(´・ω・`)ちっちぇえな

432 ：デフォルトの名無しさん：2009/02/18(水) 01:00:53

>>430
APIで出来るのは、
接続してないソケットにsockaddrをbindすることだけです。
accept以外には、UDP等で使います。

433 ：デフォルトの名無しさん：2009/02/18(水) 01:20:57

>>431
煽るなよぅ

>>432
システム上できるけどAPIが提供されていないので出来ない
という解釈でいいんでしょうか。

あると便利なんだけどなあ・・・

434 ：デフォルトの名無しさん：2009/02/18(水) 01:28:41

便利じゃないです。良く勉強してください。

435 ：デフォルトの名無しさん：2009/02/18(水) 02:01:14

>>434
便利じゃないのか・・・
勉強してきます・・・

436 ：デフォルトの名無しさん：2009/02/18(水) 07:05:48

3way-handshakeが完了した時点で、
(クライアント：connect成功、サーバ：accept成功)
<sIP,dIP,sPort,dPort>の４つ組は決定するわけで、
そのあとで、「やっぱりポート変えたいんだけど」とか
TCP的にもありえないよね。

437 ：デフォルトの名無しさん：2009/02/18(水) 09:07:23

Acceptの返すのはTCP接続が確立したソケットだからね。
Acceptしているソケットは、接続のターゲットになっているわけだから、
同じsockaddrを持つソケットが複数存在しては、
接続要求をどこでこなせばいいか、kernelに分からない。
UDPソケットへの配送についても同様。
複数のソケットに同じsockaddrをbindする必要がない。
だから出来ない。してはいけないことだから出来ない。

438 ：デフォルトの名無しさん：2009/02/18(水) 22:12:34

>>436
確かにコネクションが完了した後に変更はありえないですね。
でも、それはbindのEINVAL（もうアドレスが設定してある）みたいにすれば
問題ない気もするんですけど、どうでしょう。

>>437
んー、確かに危険だとは思うのですが。

例えばソケットを2つ作って違う場所にconnectするとして
現状同じsrcAddrとPortをbindすることはできませんよね。
これができると使用するPortが少なくてすむかなと思いました。

少ないと何かいい事あるかどうかはアレですが・・・

439 ：デフォルトの名無しさん：2009/02/18(水) 22:15:00

>>436
FTP

440 ：デフォルトの名無しさん：2009/02/18(水) 22:20:16

>>438
「危険」なんて関係ない。
意味のないことだからできない。
無意味なAPIを提供する意味はない。

441 ：デフォルトの名無しさん：2009/02/18(水) 22:21:20

>>439
FTPはデータとコントロールが別接続。
データ接続は複数もって並列にやり取りできる仕様。

442 ：デフォルトの名無しさん：2009/02/18(水) 22:33:39

>>438
少しOSの身になって考えてみよう

> 例えばソケットを2つ作って違う場所にconnectするとして
> 現状同じsrcAddrとPortをbindすることはできませんよね。

外部から入ってきたデータを、同じsrcAddrとPortを持ってるコネクションのうち、
どっちのコネクションに配送すればいいかを、どうやって決めたらいいんだ？

443 ：デフォルトの名無しさん：2009/02/18(水) 22:40:17

それを識別するために、TCP, UDP層の「アドレス」付加分として
新たにポート番号を付加して、配送先を一意に決められるようにしたのに、
30年近くたって>>418が突然、複数のソケットに付けられないのは不便じゃない？とw

郵便番号も複数の離れた土地に割り当てられたら便利かもね(棒読み)

444 ：デフォルトの名無しさん：2009/02/18(水) 22:59:12

初心者です。質問させてください。
<form action="sso-redirect" method="post" name="loginForm"> と書いてあるとき
、postメソッドで投げる先は https://sec-sso.click-sec.com/loginweb/sso-redirect
で間違いないのでしょうか。よろしくおねがいします。

445 ：デフォルトの名無しさん：2009/02/18(水) 23:00:30

初心者です。質問させてください。
https://sec-sso.click-sec.com/loginweb/で表示されたhtmlに
<form action="sso-redirect" method="post" name="loginForm"> と書いてあるとき
、postメソッドで投げる先は https://sec-sso.click-sec.com/loginweb/sso-redirect
で間違いないのでしょうか。よろしくおねがいします。

446 ：デフォルトの名無しさん：2009/02/18(水) 23:07:48

>>440
やっぱりこれが一番の問題なんだろうな。
意味がないと理解できていないんですorz

>>.442
TCPだとacceptで取得したソケットはこれをやっていて
理由は>>420さんが書いてるように４組で識別しているからだと理解しています。

>>443
確かに、みんなこれでやってるのに疑問に思うのが問題ですよね・・・
何かの理解が足りていないと思われるorz

なんか長くなってしまったので、ここまでにしたいと思います。
色々勉強になりますた。
答えてくれた方々ありがとー♪

447 ：デフォルトの名無しさん：2009/02/18(水) 23:11:17

>>445
正しい場合が多いが、そうでない場合もある。<base>

448 ：デフォルトの名無しさん：2009/02/18(水) 23:13:55

TCP/IPのことで聞きたいのですがよろしいですか？

449 ：デフォルトの名無しさん：2009/02/18(水) 23:15:58

質問させていただきます。

450 ：デフォルトの名無しさん：2009/02/18(水) 23:16:36

>>448 なに？

451 ：デフォルトの名無しさん：2009/02/18(水) 23:17:23

TCPの接続を四つ組で一意に表すと考えたのは誰なんだろ。
うまいこと考えたもんだな。特に非対称の接続の時。

452 ：デフォルトの名無しさん：2009/02/18(水) 23:17:27

>>448
よろしいです。

453 ：デフォルトの名無しさん：2009/02/18(水) 23:21:01

これから10Mバイトの容量のデジカメ写真のデータをインターネット上の電子メールで送信しようとするところである。
10Mバイトと容量が大きいので、インターネット上をそのまま一つの10Mバイトのデータ送信する事ができない。
TCP/IPではこのデータをどのように分割して処理し、分割したデータのそれぞれが間違いなく送信の相手に届くように保証しているかIPとTCPの送信側、受信側それぞれの役割別に具体的に説明しなさい。
とあるのですが、まったくわかりません；

454 ：デフォルトの名無しさん：2009/02/18(水) 23:21:40

>>446
> 確かに、みんなこれでやってるのに疑問に思うのが問題ですよね・・・
つか、疑問に思った君は偉いと思うよ、マジで…

455 ：デフォルトの名無しさん：2009/02/18(水) 23:22:30

>>453
わからないのは、君のせいではなく、その文章を書いた人間がバカだからです。

「日本語でおｋ」と言ってやりなさい。

456 ：デフォルトの名無しさん：2009/02/18(水) 23:23:10

>>455
ΣΣΣ
単位がもらえなくな・・・ｒｙ

457 ：デフォルトの名無しさん：2009/02/18(水) 23:23:58

そんなバカから単位を貰う必要はない。

458 ：デフォルトの名無しさん：2009/02/18(水) 23:24:24

助けてください。

459 ：デフォルトの名無しさん：2009/02/18(水) 23:25:54

>>458 RFC 読めばいいと思うよ

460 ：デフォルトの名無しさん：2009/02/18(水) 23:27:32

>>459
拝見させていただきます。

461 ：デフォルトの名無しさん：2009/02/18(水) 23:28:58

日本語表記please。

462 ：デフォルトの名無しさん：2009/02/18(水) 23:32:56

>>453
バカな問題を好意的に解釈すると、

「分割」はIP、「間違いなく送信の相手に届くように保証」はTCPが行っている。
説明は下記を参照。

＠IT：連載基礎から学ぶWindowsネットワーク第10回　IPパケットの構造とIPフラグメンテーション　2．IPフラグメンテーション
http://www.atmarkit.co.jp/fwin2k/network/baswinlan010/baswinlan010_03.html

＠IT：連載基礎から学ぶWindowsネットワーク第14回　信頼性のある通信を実現するTCPプロトコル（その1）
http://www.atmarkit.co.jp/fwin2k/network/baswinlan014/baswinlan014_01.html

463 ：デフォルトの名無しさん：2009/02/18(水) 23:33:57

>>462
神様ありがとう。

464 ：デフォルトの名無しさん：2009/02/18(水) 23:38:11

僕に友達をくれて。

465 ：デフォルトの名無しさん：2009/02/18(水) 23:47:14

僕を妖精にしてくれて。

466 ：デフォルトの名無しさん：2009/02/18(水) 23:48:11

>>453
馬鹿な出題者が、解答者たちが、
TCPを真面目に勉強していることに大いに甘んじ、
出鱈目な言葉使いで、質問を出してる。
ところが、>>448はTCPの事はまるで勉強してないので
チンプンカンプンである。
これは馬鹿同士の衝突現象といえよう。
古典的なシェアードバスのEthernetコリジョンと同じである。

467 ：デフォルトの名無しさん：2009/02/18(水) 23:49:27

>>462
> 「分割」はIP

ちょww

468 ：デフォルトの名無しさん：2009/02/19(木) 00:19:19

ラスカルに会わせてくれて

469 ：デフォルトの名無しさん：2009/02/19(木) 00:33:15

ラスカルに会わせてくれて

470 ：デフォルトの名無しさん：2009/02/19(木) 10:58:32

ありがとう僕の友達

471 ：デフォルトの名無しさん：2009/02/19(木) 15:03:19

オスカルに会わせてくーれーーてー

472 ：デフォルトの名無しさん：2009/02/19(木) 15:12:23

>>471
この手の書き込みをする奴の精神構造が理解できない

473 ：デフォルトの名無しさん：2009/02/19(木) 15:52:50

同意

474 ：デフォルトの名無しさん：2009/02/19(木) 16:02:33

パスカルくらいにしとけば良かったのに。

475 ：デフォルトの名無しさん：2009/02/19(木) 16:26:27

GetIfTableでアドレステーブルを取得できますが、若い番号であるほど
優先順位が高い、という解釈であってますか？

476 ：デフォルトの名無しさん：2009/02/19(木) 17:45:43

bOrder
　　[in] Specifies whether the returned interface table
　　should be sorted in ascending order by interface index.
　　　　　　　　　　　　　　~~~~~~~~~~~~~~~~~
昇順ですな。

477 ：デフォルトの名無しさん：2009/02/19(木) 17:51:25

あ、そうだったのか！
今までユーザーに選択させてたよ

478 ：デフォルトの名無しさん：2009/02/19(木) 19:18:45

>462
TCPって、connection成立時にMSSが判るから、
IPのDFビットを立てたりするんだよね。

479 ：デフォルトの名無しさん：2009/02/19(木) 22:18:59

みんなUDPのサーバーってrecvfrom使ってるの？
ログインしたあと何回かやりとりするような仕様だと毎回recvfromでもらったアドレスからユーザー判別するのが
すごい無駄な気がするんだけどいい方法ないかな？

480 ：デフォルトの名無しさん：2009/02/19(木) 22:47:45

>>463-474
友達に聞いたんだけど
高校受験の時の面接で試験官が
突然ゴレンジャーの話をし始めたらしい
人生が懸かった試験だけに
どう対応して良いか分からなかったそうだけど
まともに相手をした受験生が落とされたらしい

481 ：デフォルトの名無しさん：2009/02/19(木) 23:11:41

単に頭が悪くて落ちた馬鹿が落ちたのをゴレンジャーのせいにしてるだけだろ。

482 ：デフォルトの名無しさん：2009/02/20(金) 00:09:29

>>479
そういう時はconnectするんだよ。

483 ：デフォルトの名無しさん：2009/02/20(金) 00:57:49

それってソケット新しく作ってconnectするってことだよね？
試したけどうまくいかなかったんだよなー
ちゃんとやればできるのか
もう一回チャレンジしてみる

484 ：デフォルトの名無しさん：2009/02/20(金) 04:46:12

サーバー側がacceptしてるときに、想定しているクライアントが接続してきたのか
流しのクライアントが偶然たどりついたのか、どうすれば判別できますか？

485 ：デフォルトの名無しさん：2009/02/20(金) 06:13:15

認証しろ

486 ：デフォルトの名無しさん：2009/02/20(金) 08:42:16

>>484
っcrypto

487 ：デフォルトの名無しさん：2009/02/21(土) 03:23:57

うまくいかないにゃー

488 ：デフォルトの名無しさん：2009/02/21(土) 16:30:19

ぬるぽ

489 ：デフォルトの名無しさん：2009/02/21(土) 17:30:21

>>480
がっこうなんて人生が懸かるような所じゃないよ

490 ：デフォルトの名無しさん：2009/02/21(土) 17:55:13

>>489
だれが上手いこと書けと

491 ：デフォルトの名無しさん：2009/02/22(日) 12:37:13

ガッ

492 ：デフォルトの名無しさん：2009/02/22(日) 13:07:48

>>491
>489がもう叩いてる

493 ：デフォルトの名無しさん：2009/02/22(日) 23:17:59

ちんこかゆい90円

494 ：デフォルトの名無しさん：2009/03/03(火) 00:09:49

ソケットインターフェースで（例えばrecvを使って）、たくさん流れてくるTCPのヘッダだけ読んで、ペイロードを読み捨てる（recvしない）ってことできる？
できるとしたら、どうすればいいの？

495 ：デフォルトの名無しさん：2009/03/03(火) 08:18:50

>>494
> ソケットインターフェースで（例えばrecvを使って）、たくさん流れてくるTCPのヘッダだけ読んで

Rawソケットでできる。

> ペイロードを読み捨てる（recvしない）ってことできる？

自分(ユーザー空間)で捨てるのが嫌だということなら、
カーネル内でプロトコルスタック書く必要がある。

496 ：494：2009/03/03(火) 10:30:27

>>495
つまり出来ないのね。ありがとう。

497 ：デフォルトの名無しさん：2009/03/03(火) 16:27:51

>>496
どうしても socket じゃないとまずいのか?
BPF とか pcap ライブラリ使ってフィルタするんじゃだめなのか?

498 ：デフォルトの名無しさん：2009/03/03(火) 21:23:29

>>497
まずくはないが、今はsocketインターフェースでの可能性を知りたい。

499 ：デフォルトの名無しさん：2009/03/03(火) 21:47:52

libpcapはソケット使ってるだろ。

500 ：デフォルトの名無しさん：2009/03/03(火) 22:58:00

OSによるんじゃね

501 ：デフォルトの名無しさん：2009/03/04(水) 22:32:32

RAW ソケットも Socket インターフェイスなわけだが。

502 ：デフォルトの名無しさん：2009/03/04(水) 23:11:20

RAWソケットじゃあ、ヘッダだけ読んで、ペイロードを読み捨てる（recvしない）ことは出来ないだろ。
読まないとヘッダかペイロードか判断できないし。

503 ：デフォルトの名無しさん：2009/03/04(水) 23:18:08

ちなみにRAWでやるってことはTCPのやりとりも自分で全部書くってことか？
捨てるだけでなく返事をせんと次のが来ないぞ。

504 ：デフォルトの名無しさん：2009/03/04(水) 23:24:22

誰に言ってるの？

505 ：503：2009/03/05(木) 00:00:10

>>504
>>>495-502

506 ：デフォルトの名無しさん：2009/03/05(木) 08:37:45

なんで、ちなみになんだ

507 ：デフォルトの名無しさん：2009/03/06(金) 00:44:54

千奈美ちゃんと生でやってるんだろ。

508 ：デフォルトの名無しさん：2009/03/08(日) 21:59:11

#include<wininet.h>（
wininet.libをリンク（プロジェクトに参加させている）

LNK2001: 外部シンボル "__imp__InternetOpenA@20" は未解決です。

lpinet->hInternet = InternetOpen("myftp01",
INTERNET_OPEN_TYPE_DIRECT,
NULL,
NULL,
0 );
とすると
LNK2001: 外部シンボル "__imp__InternetOpenA@20" は未解決です。
がでてしまいます。原因がわかりません。どなたかご教授願います。
wininet.libをプロジェクトに参加させているだけでは「リンク」されないのでしょうか？

509 ：デフォルトの名無しさん：2009/03/08(日) 22:01:44

ｽﾚ違い
処理系のリンカの使い方を読め

510 ：デフォルトの名無しさん：2009/03/09(月) 01:37:41

質問させていただきます。
プロミスキャスモードとは、自分に流れてくる、本来廃棄される別のアドレス宛のデータも拾うということですよね？
そのひろったデータは再度自分が送信しないと本来受け取るはずだったあて先には届かないのでしょうか？

511 ：デフォルトの名無しさん：2009/03/09(月) 01:40:22

本来の受け取り人に届くかどうかに影響するわけないやろー

512 ：デフォルトの名無しさん：2009/03/09(月) 01:40:44

プロミスキャスモードでぐぐれ。

513 ：デフォルトの名無しさん：2009/03/09(月) 02:26:50

>>510
A-B間の通話を盗聴してもAもBも気づかないのと同じ

514 ：デフォルトの名無しさん：2009/03/09(月) 13:20:27

■promiscuous {形} : ごたまぜの、入り交じった、無差別の、乱交の、ふしだらな

ごたまぜモード？
入り交じりモード？
無差別モード？
乱交モード？
ふしだらモード？

どの意味なんでしょうか？

515 ：デフォルトの名無しさん：2009/03/09(月) 13:27:01

イーサネットはばらまいて、必要なやつがそれを拾うから
たまたま自分とこに来たやつ全部拾って見てる。
ルーターやスイッチングハブの先は必要ない場合こないけど。

516 ：デフォルトの名無しさん：2009/03/09(月) 15:17:13

トークンリングだと再送してやらないといけないよな？

517 ：デフォルトの名無しさん：2009/03/09(月) 15:46:04

まああれはバケツリレーだしな

518 ：デフォルトの名無しさん：2009/03/09(月) 21:51:20

>514
だからプロミスキャス*モード*でぐぐれっての
ttp://www.google.co.jp/search?q=%E3%83%97%E3%83%AD%E3%83%9F%E3%82%B9%E3%82%AD%E3%83%A3%E3%82%B9%E3%83%A2%E3%83%BC%E3%83%89&sourceid=navclient-ff&ie=UTF-8&rlz=1B3GGGL_ja___JP225

519 ：デフォルトの名無しさん：2009/03/09(月) 23:15:28

>>518
分かりました。　けど「プロミスキャス」ってどういう意味なのか理解したいと
思って。　日本語無いんですか？

520 ：デフォルトの名無しさん：2009/03/09(月) 23:54:35

promiscuous
誰とでも寝る(性的な意味で)

521 ：デフォルトの名無しさん：2009/03/10(火) 00:00:36

なるほど。　特定のIPアドレスの書いてあるおちんちんだけでなく、
どんなおちんちんでも受け入れるモードなんですね。

522 ：デフォルトの名無しさん：2009/03/10(火) 00:13:23

>>519
ある単語が他言語の単語と一対一対応する事はほとんど「ない」

523 ：デフォルトの名無しさん：2009/03/10(火) 00:51:52

>>519
無差別モード

524 ：デフォルトの名無しさん：2009/03/12(木) 12:23:19

Winsockを使ったプログラムで、Exeファイル側とExeが読み込むDll側の両方でWinsockの関数を使う場合、ExeとDll両方でStartUpを呼ばないといけないんですか？
Exe側で呼び出していれば、Dll側は呼ばなくてもいいと思っていたんですが。

525 ：デフォルトの名無しさん：2009/03/12(木) 17:44:03

StartUpしてから呼ぶことと言う仕様であればいいんじゃね

526 ：デフォルトの名無しさん：2009/03/18(水) 19:29:06

linuxなら、ipヘッダーを変更して、パケットを送信するのって、簡単に出来るのだが
windows環境では、というか。VCではできないのでしょうか
同じTCP/IPプロトコルなのに・・・・

527 ：デフォルトの名無しさん：2009/03/18(水) 20:21:06

>>526
rawソケットが使えますよ。

528 ：デフォルトの名無しさん：2009/03/18(水) 20:48:03

>>527
もちろんlinuxでip変更するのに、rawソケットを変更するんですが
windowsの場合、rawソケットは、変更できないのでは？

529 ：デフォルトの名無しさん：2009/03/18(水) 20:51:35

言葉足らずで申し訳ない
ipを変更した、TCP データをrawソケット経由では送信できないっていう、意味合いです。

530 ：デフォルトの名無しさん：2009/03/18(水) 21:01:54

>>529 具体的に何がしたいんだ?

struct ip_header = malloc(...);
ip_header.ip_adress = <an_address>;
ip_header.....
....
send(... <a ip_header includes an_addressr> ...)

...
ip_header.ip_addres = <another_address>;
...
send(... <a ip_header includes another_address> ...)

みたいなことをしたい場合, おそらく OS の実装による

531 ：デフォルトの名無しさん：2009/03/18(水) 21:14:01

>>530
大体そういったところです、任意のTCPデータのicpmをwindowsで生成する方法です
誤解してほしくないのは、syn floodやディニアルを行うのが目的ではなく
サーバーがそれらのアタックを受けているので、シュミレーションが目的です
すでに、syn floodやdosはlinuxで実装しているのですが、windowsのほうがてっとり早いので聞いて見ました
ちなみにWindows XP SP2です

532 ：デフォルトの名無しさん：2009/03/18(水) 21:16:51

訂正です
訂正前
サーバーがそれらのアタックを受けているので、シュミレーションが目的です
訂正後
管理するサーバーがそれらのアタックを受けているので、自サーバーに向けてのシュミレーションが目的です

533 ：デフォルトの名無しさん：2009/03/18(水) 21:20:35

それいうならシミュレーションやー

すまん、くだらんつっこみだった

534 ：デフォルトの名無しさん：2009/03/18(水) 21:32:34

XP SP2移行ではraw socketは使えない。SP1なら、
http://support.microsoft.com/kb/897656/ja なんだが。

> windowsのほうがてっとり早いので
このくらいの理由ならLinuxで書け。
クラックツール用のネットワークドライバがあるが正直お勧めしない。

535 ：デフォルトの名無しさん：2009/03/18(水) 21:35:34

>>534
なぜお薦めしないの？

536 ：デフォルトの名無しさん：2009/03/18(水) 21:41:13

つ「セキュリティ上の問題が発見されました！」

537 ：デフォルトの名無しさん：2009/03/18(水) 21:43:51

>>531ですが
> windowsのほうがてっとり早いので
の理由です
linuxの環境が、runlevel3のcuiなので、vimでゴリゴリ書いて、デバッグするのに疲れるんだよね
せめてIDEがEclipseが使えれば、楽なのですが、Visual studioが慣れているし
デバッグもしやすいしからなんだけどね。

538 ：デフォルトの名無しさん：2009/03/18(水) 21:46:24

まだ何か言いたいことでもあるのか?

539 ：デフォルトの名無しさん：2009/03/18(水) 21:50:57

>>537
startxすればいいんじゃね?

540 ：デフォルトの名無しさん：2009/03/18(水) 21:55:26

>>531です
>>539
そもそも、xがインストールされていなし、そのlinuxのPCもssh経由で、リモートログインしているから無理です
>クラックツール用のネットワークドライバがあるが正直お勧めしない。
その理由を教えてほしいのですが

541 ：デフォルトの名無しさん：2009/03/18(水) 22:17:10

ssh出来るんならWindowsでクロス開発だろ不通

542 ：デフォルトの名無しさん：2009/03/18(水) 22:29:29

>>531
> 任意のTCPデータのicpmをwindowsで生成する方法です

icpm kwsk

543 ：デフォルトの名無しさん：2009/03/18(水) 22:32:56

>>540
「cygwin」あたりを突っ込んでだな
$ start x
$ ssh -Yf <server> emacs
って、やれば幸せになれないか？

544 ：デフォルトの名無しさん：2009/03/19(木) 00:50:31

eclipse入れたLinuxで開発して、runlevel3とかいうマシンに持っていけばいいやん。
大したコード量じゃないんだから、vimでやれという気もするけど。

545 ：デフォルトの名無しさん：2009/03/19(木) 00:59:53

Windowsでのやり方聞いてるのに何でLinuxでのやり方語りだしちゃってるの？

Linuxでのやり方なんて知ってるし、リモートアクセスなんてド素人でも知ってるんだからわざわざ言うな。読んでる方が恥ずかしくなる。
お前らの知識の限界が、そこらへんなのは分かるが、レベルの低い見当違いの回答はウザいだけなんだよ。

546 ：デフォルトの名無しさん：2009/03/19(木) 01:02:08

つか、探せばシミュレータくらいあるんじゃね？

547 ：デフォルトの名無しさん：2009/03/19(木) 01:03:53

なんの？

548 ：デフォルトの名無しさん：2009/03/19(木) 01:05:03

質問者が欲しがってるようなの

549 ：デフォルトの名無しさん：2009/03/19(木) 01:10:28

あるの？

550 ：デフォルトの名無しさん：2009/03/19(木) 01:11:53

そんなもん、質問者にしかわからんだろ。

551 ：デフォルトの名無しさん：2009/03/19(木) 01:13:30

じゃ>>546は何のために書き込んだの？

552 ：デフォルトの名無しさん：2009/03/19(木) 01:17:11

自分で作らなくても、既存のものが使えるかもよっていうサジェスチョン。

553 ：デフォルトの名無しさん：2009/03/19(木) 01:18:53

で、既存のものがあるの？

554 ：デフォルトの名無しさん：2009/03/19(木) 01:21:35

ググれば出てくるよ。

555 ：デフォルトの名無しさん：2009/03/19(木) 01:24:20

無いんですね？出せないってことは

556 ：デフォルトの名無しさん：2009/03/19(木) 01:44:10

手前で作れよそれくらい。
今俺似たようなの仕事で来てて「書いた方が早い」ってのにOSS使えってんでブチキレ状態。

557 ：デフォルトの名無しさん：2009/03/19(木) 01:51:43

ググれば出てくるというのは嘘？

558 ：デフォルトの名無しさん：2009/03/19(木) 02:05:01

ググったのですか？

559 ：デフォルトの名無しさん：2009/03/19(木) 02:16:09

「ググれば出てくる」って全く情報ない無意味な書き込みだよね。死ね。

560 ：デフォルトの名無しさん：2009/03/19(木) 02:22:19

どこが情報無いんだ？

561 ：デフォルトの名無しさん：2009/03/19(木) 02:25:44

ググれば出てくるなら、リンクを提示しろ

562 ：デフォルトの名無しさん：2009/03/19(木) 02:31:04

そうだそうだ。なんで俺様がわざわざググらなくちゃいけないんだ。

563 ：デフォルトの名無しさん：2009/03/19(木) 02:58:42

煽れば誰かがググってくれるお＾＾

564 ：デフォルトの名無しさん：2009/03/19(木) 10:41:03

508046

565 ：デフォルトの名無しさん：2009/03/19(木) 13:40:46

金返せ

566 ：デフォルトの名無しさん：2009/03/19(木) 20:48:45

どうしてもWindowsでやりたいんならドライバ作るしかないよ。
実験用のPCにLinuxか何か入れてやったほうが絶対速いし簡単。

567 ：デフォルトの名無しさん：2009/03/19(木) 21:25:18

568 ：デフォルトの名無しさん：2009/03/19(木) 22:02:45

仮想記憶

569 ：デフォルトの名無しさん：2009/03/19(木) 22:54:30

> 任意のTCPデータのicpmをwindowsで生成する方法です
意味不明

570 ：デフォルトの名無しさん：2009/03/19(木) 23:40:07

>>569
お前が馬鹿なだけ

571 ：デフォルトの名無しさん：2009/03/20(金) 00:00:29

TCPデータってこの事か?
http://www.wakasato.org/learn/nepc/course2/chapter04/section05.html
> TCPセグメントはTCPヘッダとTCPデータから構成されている。

TCPデータはどんな馬鹿でも任意の物がつくれるよなあ。
icpmってなんだ? ICMPの事か? それをTCPデータに突っ込むのか?
意味不明だなあ。

572 ：デフォルトの名無しさん：2009/03/20(金) 00:12:09

むりやり解釈すると、
データ部にTCPパケットが入ってるICMPパケット
ってことじゃね？

573 ：デフォルトの名無しさん：2009/03/20(金) 00:41:51

それなら普通に作れるだろ。

574 ：デフォルトの名無しさん：2009/03/20(金) 05:06:21

http://support.microsoft.com/kb/897656/ja
を回避したいっつー話なのか？

575 ：デフォルトの名無しさん：2009/03/20(金) 09:04:45

回答者は質問者のレベルを正しく推測しなければいけない。
例えば↓このような情報から。

>>531
> シュミレーションが

576 ：デフォルトの名無しさん：2009/03/20(金) 10:17:23

趣味ではよくあること

577 ：デフォルトの名無しさん：2009/03/25(水) 12:35:44

は？

578 ：デフォルトの名無しさん：2009/03/27(金) 10:34:43

ひ？

579 ：デフォルトの名無しさん：2009/03/27(金) 13:05:55

腐

580 ：デフォルトの名無しさん：2009/03/27(金) 19:41:35

兵法：真美っ！「夢Memo！φ( . . )やぁ」猶予

581 ：デフォルトの名無しさん：2009/03/27(金) 23:14:41

はぁ？

582 ：デフォルトの名無しさん：2009/03/28(土) 11:49:35

愛国者達

583 ：デフォルトの名無しさん：2009/04/04(土) 13:43:44

584 ：デフォルトの名無しさん：2009/04/06(月) 11:23:32

普通winpcapじゃねーの？

585 ：デフォルトの名無しさん：2009/04/10(金) 11:44:22

くだらない質問＆板違いかもしれませんが、回答下さい。

去年くらいから、いろんなMMO型ネットゲーム系のブログで、Windowsの
TcpAckFrequency を1にすることで、ゲーム鯖とのレスポンスが向上して
ゲーム上有利になるテクニックが広まっているのですが、これってゲーム
鯖の負荷が高まるだけでなく、ネットワーク全体に有害ってことはないでし
ょうか？
後、Windowsソケットってのは、確認待ちのAckがある場合、送信できない
って事はないですよね？

586 ：デフォルトの名無しさん：2009/04/10(金) 12:33:06

なんとなく、答えっぽいのが Winsock Programmer's FAQ ってのに書いてあったので抜粋。

<<
3.20 - 遅延 ACK アルゴリズムとは何ですか?

TCPを単純に実装すると、受信したパケットに対して ACK パケットはすぐに返されます。
(ACK は TCP が保証している信頼性を提供するためのものです。)

現在のスタックでは、ACK は少しの時間(概して最大 200ms 程度)遅らせるようになっています。
これには三つの理由があります。
a) 「お馬鹿なウィンドウ症候群」(silly window syndrome)を避ける。;
b) ACK を返そうとしたときに返送するデータフレームの用意ができていれば、
ACK をその返送フレームに相乗りさせることができる。;
c) 遅らせた期間内にいくつかフレームが届いたら、その分の ACK を一回で返すことができる。

プロトコルスタックは、最大2フレーム分のデータまで遅らせることが許されています。
<<
1にすると即座にかえすので、a), b), c)の問題が発生するって認識ですよね・・具体的にどういう問題が発生するのかな・・

587 ：デフォルトの名無しさん：2009/04/10(金) 22:46:40

>>586
> 1にすると即座にかえすので、a), b), c)の問題が発生するって認識ですよね・・具体的にどういう問題が発生するのかな・・

通過するネットワークの性質によって異なるけど、おおむね帯域を圧迫する
方向に動くと思うよ

ex)
ethernet の場合
インターフレームギャップなるものがあって、この時間を確保するため
に帯域が圧迫される

ATM などの固定長セルを使っている場合
埋められていないセルが飛び交う頻度が増大するので帯域が圧迫される

588 ：デフォルトの名無しさん：2009/04/11(土) 09:29:48

回答どうも、ACKの頻度が増す結果ですよね。

帯域を圧迫するから自粛するように呼びかけてみます。
まあ、なっとくできる説明ができるか自信がないですが。。。

589 ：デフォルトの名無しさん：2009/04/11(土) 13:05:56

それはいかがなものかと

590 ：デフォルトの名無しさん：2009/04/11(土) 13:14:38

一部のプレイヤーだけ自主規制しても不利益被るだけだからねえ。
下手したら呼びかけた人間が逆恨みされるぞ。
本当に拙いのならゲーム制作サイドに働きかけるべきではないかと。

591 ：デフォルトの名無しさん：2009/04/11(土) 20:54:10

サーバがクライアントの応答速度に合わせて動くと
応答の速いクライアントばかりサービスされて、低速度クライアントが
その速度差以上にサービスされなくなってしまう。

クライアント環境の混在を考慮していれば、応答が多少はやかろうが
おそかろうが平等に扱うよう作るべき
でも、たいてい、そうなってないんだろうなあ

592 ：デフォルトの名無しさん：2009/04/11(土) 21:02:25

君は作ったことがないんだね？

593 ：デフォルトの名無しさん：2009/04/12(日) 19:02:20

>でも、たいてい、そうなってないんだろうなあ

素人の感想乙

594 ：デフォルトの名無しさん：2009/04/12(日) 21:19:14

>>585
これに相当するオプションはLinux/Unixで考慮されたことはないのかな？　
LAN上でデバイスの制御している時にこの遅れが問題になることがある。　

http://oss.sgi.com/archives/netdev/2001-08/msg00127.html

こんなパッチが提案されていたのを見つけたがスルーされてるw

595 ：デフォルトの名無しさん：2009/04/12(日) 22:42:58

ざっと見た感じ、ソケットオプションのTCP_QUICKACKとかじゃね？

596 ：デフォルトの名無しさん：2009/04/13(月) 00:55:21

>>595
TCP_QUICKACKは微妙だな。　良く使い方が解らん。
一回しか使えないオプションとなっている。　セットしても一回使われたらリセット
されてしまう。　けど、接続された初期状態のソケットでは常に最初はセットされるとか。

597 ：585：2009/04/14(火) 14:10:05

ゲームのブログでゲーム内のPing表示が200ms程度だったのが、30ms前後になったと
いう報告がありました。
たいがいのネットゲームの仕様的に各プレイヤーが大体200ms単位で通信していたのが
ACKが早く返る為、特定のプレイヤーのみ応答が速くなっていたのではないかと推測されます。
でも、インターネット上でそんな即時性がもとめられるゲームはどうなんでしょうね？

RFC1122日本語訳
http://www2s.biglobe.ne.jp/~hig/tcpip/HostReq_Comm.html
--------------------------------------------------------
4.2.3.2 いつ ACK セグメントを送信するか

TCP データセグメントのストリームを受信しているホストは、
受信するデータセグメントにつき、1 つ以下の ACL (肯定応答) セグメントを送信することによって、
インターネットとホストの両方の効率を増すことができる。これは "遅延 ACK" [TCP:5] として知られている。

TCP は遅延 ACK を実装すべきである (SHOULD) が、ACK を過度に遅らせるべきではない。
遅延は 0.5 秒以下でなければならず (MUST)、フルサイズのセグメントの場合は、
少なくとも毎秒セグメントに対して ACK が存在すべきである (SHOULD)。
----------------------------------------------------------

RFCによるとACKを遅らすのはSHOULDになっているので即時でも問題ではないのかもしれません。
でも、明らかに有害だと思う。

ゲーム制作サイドには一応メールしましたが・・回答ありません。

598 ：デフォルトの名無しさん：2009/04/14(火) 23:54:39

>>597
SHOULD に逆らうのなら相当慎重になる必要がある。
http://www.asahi-net.or.jp/~sd5a-ucd/rfc-j/rfc-2119j.html

599 ：デフォルトの名無しさん：2009/04/18(土) 03:14:07

プログラムの設計の話なんだけど、どこで聞けばいいか解らんかったからここで。

// select/epoll等で、読み込み可能になった場合、
// スレッドAで実行される
void Read()
{
// データを受信し、プロトコルパースしたのがmsg
// 実際はバッファリングしてたり、パースに失敗したら云々やってる。
Message msg = Message.Parse( Sock.Read() );
ThreadPool.Push( pair<msg, this> ); // パースしたmsgをスレッドプールで処理する。
}

// こっちがスレッドプール側で動くルーチン
void Task()
{
pair<Message, Handler*> item = Pop();
Message msg = item.first;
Handler *handler = item.second;
//メッセージを色々やってレスポンスを生成
Response res = ...;

handler.Send( res );
}

こんな実装なんだけど、Read()とTask()は完全に非同期で呼ばれる。
だから、Task()側で、レスポンス生成して、いざSendするじぇ。ってなったときに、
もうソケットは有効じゃないかもしれないし、Handlerのインスタンスがdeleteされてるかもしれない。
ってクソ設計になっちゃったんだけど、一般的にはどういう風にすればいいのかな
プロトコルのパースを別スレッドでやって、そのレスポンスをどうすればスマートに送り返せるか
偉い人の意見をおしえてください

600 ：デフォルトの名無しさん：2009/04/18(土) 05:27:06

使用言語くらいはかこうな

601 ：デフォルトの名無しさん：2009/04/18(土) 07:06:09

>>599
> もうソケットは有効じゃないかもしれないし、
> Handlerのインスタンスがdeleteされてるかもしれない。

普通、ソケットや Handler なんていちいち生成・削除しないと思うが...。

そういうことが必要なら、パース側で生成して、レスポンスを返す側で削除
すればいいだけだと思う。

条件によって生成・削除が入り乱れるようなケースなら、生成・削除を制御
するマネージャ作ってマネージャを介して生成・削除するようにするのがい
いと思う。

>>600
どうみても C++ だろうし、そもそも言語関係ないだろ。

602 ：デフォルトの名無しさん：2009/04/18(土) 11:17:13

答えるならサンプルコードくらいはかこうな

603 ：デフォルトの名無しさん：2009/04/18(土) 11:26:57

>>602

604 ：デフォルトの名無しさん：2009/04/18(土) 14:25:23

>>599
送るという処理と送るためのメカニズムが分離可能になっていると
そういう点で悩むことがありそうだけど、そういう時は両方をセットで
管理する第三のクラスを作って、そいつが生成・解放の管理責任と
リクエスト処理の受付インタフェースを持つようにすればいい。

605 ：599：2009/04/19(日) 18:13:57

thxです。

やっぱりマネージャを作るのがいいですかね
そもそも設計がまずいんですかねー
今作ってるのはサーバーで、
言語はC++、linux上でうごくもん書いてます。

606 ：デフォルトの名無しさん：2009/05/05(火) 14:10:21

C#でパケットキャプチャをしたいんだけど、ソースください

607 ：デフォルトの名無しさん：2009/05/05(火) 18:33:49

いくらで買い取ってくれる？

608 ：デフォルトの名無しさん：2009/05/06(水) 19:07:17

1000wonくらいでどうだろうか？

609 ：デフォルトの名無しさん：2009/05/10(日) 03:06:11

1000wonで10行売ってやる。

610 ：デフォルトの名無しさん：2009/05/10(日) 11:10:47

ニダ

611 ：デフォルトの名無しさん：2009/05/10(日) 16:01:15

Linuxでsocket通信を使った簡単なプログラムを書きました。
同じマシン内(host=localhsot)ではで正しく通信を確認できましたが、
他のPCからはつながりません。
(ルータなどはいってない単純な閉じたネットワークです)
こういう場合はなにから確認すればよいでしょうか。

# pingとおって、sshでログインして作業しているのでネットワーク自体はOKです。
# netstat -an は、tcp 0 0 0.0.0.0:9876 0.0.0.0:* LISTEN と、指定したポートでListen
# しているみたいです。
# tcpwrapperどうなってるかわからないけど/etc/hosts.allow はALL:ALLと記述してみました。

612 ：デフォルトの名無しさん：2009/05/10(日) 16:08:18

iptablesとか。
snoopしてみれば

613 ：デフォルトの名無しさん：2009/05/10(日) 17:28:55

どこでこけてるかチェックして、そのときのperror()を貼ればすぐに解決すると思うよ

614 ：デフォルトの名無しさん：2009/05/10(日) 18:11:44

ループバックやめて２台のＰＣでやりはじめたら
繋がらないといってるからこけるところないだろ・・・。

615 ：デフォルトの名無しさん：2009/05/10(日) 18:21:52

どこもこけずにつながらないんならプログラムのバグじゃない？
pingは通ってるからネットワークの問題ではないんだし。
どこかでこけるからつながらないんじゃないの？

616 ：デフォルトの名無しさん：2009/05/10(日) 18:27:42

listenしてるいってるし・・・。

617 ：デフォルトの名無しさん：2009/05/10(日) 18:28:25

接続先のＩＰ間違ってるとか
その手だろ。

618 ：デフォルトの名無しさん：2009/05/10(日) 18:43:55

ファイアウォールで引っかかってる可能性が高い。まァその場合はconnectが失敗すると思うけどね。

619 ：デフォルトの名無しさん：2009/05/10(日) 19:12:50

linuxならnmapのパッケージ入れてポート開いているのが見えるかチェックしてみれば問題切り分けの一歩になると思うぞ

620 ：デフォルトの名無しさん：2009/05/11(月) 10:15:44

　　　　　　　＿＿＿_
　　　　　　／　　　　＼
　　　　／　　─　　 ─＼
　　　／　　（●）　（●）＼
　　　|　　　　（__人__）　　 | それは盲点だったお
　　　/　　　　 ∩ノ ⊃　　／
　　　(　＼　／＿ノ　|　 |
　　　|.＼　“　　／＿＿|　 |
　　　|　. ＼／＿＿＿／　

621 ：デフォルトの名無しさん：2009/05/11(月) 12:53:54

winsock2で、あるスレッドがSleepで待機している間に、
別のスレッドでselectを呼び出すと失敗するんですが、何か使い方が間違ってるんでしょうか。
それとも別の原因なんですかね。

622 ：デフォルトの名無しさん：2009/05/11(月) 17:59:58

失敗したときはエラー番号を提示するのが紳士のたしなみ

623 ：デフォルトの名無しさん：2009/05/12(火) 14:02:59

UNIXで、acceptがエラー返す条件って何がある？
引数エラーとかそういうの以外で

624 ：デフォルトの名無しさん：2009/05/12(火) 14:13:22

よくあるのは、ソケット開きすぎ。
いずれにせよerrno調べればなんかわかるんじゃね？

625 ：デフォルトの名無しさん：2009/05/12(火) 14:15:20

>>623
いろいろあるような。
ttp://www.linux.or.jp/JM/html/LDP_man-pages/man2/accept.2.html#lbAG

626 ：デフォルトの名無しさん：2009/05/12(火) 22:41:49

EINTRはエラーじゃないよねえ

627 ：デフォルトの名無しさん：2009/05/13(水) 12:36:25

何言ってんの？

628 ：デフォルトの名無しさん：2009/05/13(水) 13:35:25

プログラマが予期しない、正常な動作を妨げる事象が
エラーでないはずがない。

629 ：デフォルトの名無しさん：2009/05/13(水) 13:37:30

仕様と呼ばれる事もあるので>>628は間違い。

630 ：デフォルトの名無しさん：2009/05/13(水) 13:44:51

それは、エラーが発生するのが正しい仕様ですってことでは？

631 ：デフォルトの名無しさん：2009/05/13(水) 16:56:17

んじゃ、EWOULDBLOCKもエラーじゃないよねえ

632 ：デフォルトの名無しさん：2009/05/13(水) 17:03:20

didn't complete successfully = error

633 ：デフォルトの名無しさん：2009/05/16(土) 06:55:03

CAsyncSocketとCAsyncMonikerFileって何が違うんですか？
URLからソース取得するだけならCAsyncMonikerFileで問題ないですか？CAsyncSocketでもできるんでしょうか？Winsock2のほうが簡単ですか？

634 ：デフォルトの名無しさん：2009/05/16(土) 06:56:08

上げさせてください

635 ：デフォルトの名無しさん：2009/05/18(月) 10:13:35

BDSソケットのaccept(2)について質問

sockaddr構造体って、アドレス種別によって大きさが変わるらしいけど
それってIPv4かIPv6のどちらかわからないときはどうするの？

636 ：デフォルトの名無しさん：2009/05/18(月) 10:27:27

>>635
ソケット開く時点でv4/v6の指定するので、acceptの時点でどちらで待ってるのかは知ってるはずだけど。
もし知らないなら、サイズの大きいほうを指定しておけばよい。

637 ：デフォルトの名無しさん：2009/05/18(月) 10:45:11

>>636
ありがとうございます。
ソケット開く時点でv4/v6の指定をしない（AF_UNSPEC）ので
どっちかわかんねーんだよどちらなのかわからないんです。

638 ：デフォルトの名無しさん：2009/05/18(月) 11:20:56

pingの仕組みはなんですか？

639 ：デフォルトの名無しさん：2009/05/18(月) 11:26:38

>>638
echo reqeust出して、echo reply受信する。

640 ：デフォルトの名無しさん：2009/05/18(月) 11:45:52

ソース見れ

641 ：デフォルトの名無しさん：2009/05/18(月) 12:30:29

いわゆるオプソなソースは目が腐るので見ない方が良いね。ソース儲は滅びて欲しい。

参照するならRFC
http://www.faqs.org/rfcs/rfc792.html

642 ：デフォルトの名無しさん：2009/05/18(月) 14:21:19

>>641
君が貶めるLinuxコミュニティーがRFCを制定しているのだがね。

643 ：デフォルトの名無しさん：2009/05/18(月) 14:34:34

いつのまにかIETFはLinuxコミュニティになったのか。
そのうちIETFディストリとかできるのか。
すげーな。

644 ：デフォルトの名無しさん：2009/05/18(月) 14:46:56

今やUNIXといったら実質Linuxを指すからな。
バカボンの主人公がバカボンのパパみたいなもんだろ。

645 ：デフォルトの名無しさん：2009/05/18(月) 14:47:23

> LinuxコミュニティーがRFCを制定している
> LinuxコミュニティーがRFCを制定している
> LinuxコミュニティーがRFCを制定している
> LinuxコミュニティーがRFCを制定している
> LinuxコミュニティーがRFCを制定している
> LinuxコミュニティーがRFCを制定している
> LinuxコミュニティーがRFCを制定している
> LinuxコミュニティーがRFCを制定している
> LinuxコミュニティーがRFCを制定している
> LinuxコミュニティーがRFCを制定している

646 ：デフォルトの名無しさん：2009/05/18(月) 14:52:16

>>644
サンプル実装で Unix 系の OS が多いのは事実だが IETF と Unix は無関係

CISCO の IOS が Unix で動いてるわけじゃないし、その他のメーカのネット
ワーク機器にしたって Unix で動いているものの方が少ない.

647 ：デフォルトの名無しさん：2009/05/18(月) 14:52:56

こまけぇやつだな。
そんな事どうでもいいんだよ。

648 ：デフォルトの名無しさん：2009/05/18(月) 14:55:36

>>646
その通り。
今ではほぼすべてがLinuxで出来ている。

649 ：デフォルトの名無しさん：2009/05/18(月) 15:24:39

犬糞臭いｽﾚになってまいりました。

650 ：デフォルトの名無しさん：2009/05/18(月) 15:31:09

オープンソース=Linuxと直結しちゃってるあたりが終わってるよな。

651 ：デフォルトの名無しさん：2009/05/18(月) 15:36:39

>>650
The Internet Engineering Task Force (IETF) is a large open source
community of network designers, operators, any Linux vendors,
and researchers concerned with the evolution of the Internet
architecture and the smooth operation of the Internet.

652 ：デフォルトの名無しさん：2009/05/18(月) 15:56:16

>>651 捏造乙

http://www.ietf.org/overview.html
The Internet Engineering Task Force (IETF) is a large open international community of
network designers, operators, vendors, and researchers concerned with the evolution of
the Internet architecture and the smooth operation of the Internet. It is open to any
interested individual. The IETF Mission Statement is documented in RFC 3935.

653 ：デフォルトの名無しさん：2009/05/18(月) 16:27:32

マジなのかネタなのか釣りなのか自演なのかよくわからん流れだな。

654 ：デフォルトの名無しさん：2009/05/18(月) 16:28:34

>>652
もったいぶった専門用語使っても
しゃべればしゃべるほど何にも知らない素人だと宣伝してるようなもんだ
もう黙れ

655 ：デフォルトの名無しさん：2009/05/18(月) 17:22:49

>>654
> LinuxコミュニティーがRFCを制定している
ソース出せないだろ。引っ込んでろ。

656 ：デフォルトの名無しさん：2009/05/18(月) 19:07:14

shutdown()呼ばずにclose()呼んだ時に起き得る問題ってなに？

657 ：デフォルトの名無しさん：2009/05/18(月) 19:14:00

アプリケーションレベル以上の問題は起こらないんでないの？

658 ：デフォルトの名無しさん：2009/05/18(月) 21:48:45

http://www.kt.rim.or.jp/~ksk/sock-faq/unix-socket-faq-ja-2.html#ss2.6

659 ：デフォルトの名無しさん：2009/05/21(木) 04:25:27

ゲ製と迷ったんですがこちらで質問させてください。

TCPにてキー入力情報のみをお互いやり取りし、受信完了まで待つことで
同期を取るタイプの少人数対戦ゲームを作っています。
受信待ちに時間がかかりFPSが思うように出ないため、Kailleraなどの
ゲーム/ツールによく見られるようなキーバッファを持たせようと思うのですが、
バッファをどのように利用しているのかがよくわかりません。

1.一定フレーム毎にキー情報をまとめて受信する。
（一回の受信量は増えるが、密度が減り安定する）
2.毎フレームキー情報を受信するが、処理し始めるは数フレーム後。
（逐一届いたものからキューに溜める。事前に貯金しておくイメージ？）

どちらの方法が妥当でしょうか。あるいは外に方法はありますか？
とりあえず1の方法で実装してみたのですが、LAN内だと問題ないものの
ネット越しに通信を行うと毎回1～5分後に急にFPSが下がってしまい……
（自分のコーディングミスとは思いますが）

660 ：デフォルトの名無しさん：2009/05/21(木) 11:32:16

ウインドウの問題かな？

661 ：デフォルトの名無しさん：2009/05/21(木) 14:02:33

TPC/IP自体がやってることだから
アプリレベルでの調整なんて屋上屋でしかないな。

もしかしてキー情報の受信をブロッキングでやってるって話か？
関数から制御が戻るまでメインのループが停止する？
だとしたらフレームレート下がるの当たり前だ。
サブスレッドで送受信するなり非同期APIつかうなりに書き換えた方がいい。

>ネット越しに通信を行うと毎回1～5分後に急にFPSが下がってしまい……
>（自分のコーディングミスとは思いますが）
この挙動見る限りそれ以前のバグって気がするが

662 ：デフォルトの名無しさん：2009/05/21(木) 14:14:48

> TCPにてキー入力情報のみをお互いやり取りし、受信完了まで待つことで
> 同期を取るタイプ
この設計が悪いという気がするが、
ネットワークプログラミング的に注意する点は、TCPだとソケットに書き込んだ
時点ですぐにパケットが出るとは限らないってことくらいだな。

663 ：デフォルトの名無しさん：2009/05/21(木) 14:30:41

安易にメガ単位のデータ送りまくってるんなら
送信データが最小になるようなプロトコルの改善も必要。

664 ：デフォルトの名無しさん：2009/05/22(金) 01:31:44

リアルタイムゲームならUDPで投げっぱなしが基本じゃね？
同期を取るならサーバ側が持ってる情報を各クライアントに投げれば良いんだし

双六とかカードゲームとか
延滞が発生しても問題ないタイプならTCPで良いだろうけど

665 ：デフォルトの名無しさん：2009/05/22(金) 10:57:20

libwrapの使い方を説明してるところ教えて。

666 ：デフォルトの名無しさん：2009/05/22(金) 11:54:16

特定のサイトの文章をローカルに保存するようなアプリケーションはどのように作ればいいですか？
具体的にはニュースサイトの特定の単語を含む記事をまとめられるようにしたいわけです。
無作為に大量に保存をしておいてそこから検索をかける形にするか、
枠に入力した単語に関するものだけを集めていくのかはまだ決めていませんが。

667 ：デフォルトの名無しさん：2009/05/22(金) 11:56:34

wgetで集めりゃいいんじゃないの？
Windows？

668 ：デフォルトの名無しさん：2009/05/22(金) 11:58:48

>>666
wgetで取得 -> 検索によるフィルタリング -> HTMLを整形
かな。

669 ：デフォルトの名無しさん：2009/05/22(金) 12:12:06

googleの
site:microsoft.com keyword
でいいじゃん

ム板的にはHTTPで落としてhtml解析して
更にリンク先に飛ぶというのを再帰的に繰り返していく

安易に大量のデータさらいまくると怒られるかもしれないぞ

670 ：デフォルトの名無しさん：2009/05/22(金) 12:31:03

>667 Windowsです。
>668 ありがとう。それでやってみます。
>669 そういう手もありますね。なるほど。負荷に気をつけてやります。

671 ：デフォルトの名無しさん：2009/05/22(金) 12:34:43

robots.txt 無視したら怒りを買うのは必至。

672 ：デフォルトの名無しさん：2009/05/23(土) 00:24:56

robots.txtって何？で、ちゃんと設定されてない可能性もあるので(ry
特にウェブデザイナが作ってる様なサイトは(ry

制御用の即応性と、大量のデータの転送時の速度の両方が欲しい時は、
FTPみたいに、バッファリング無しのストリームと、バッファリングありのストリームの２本張って使い分けるのが順当かな？
繋ぎ直して１本でがんばって使い分けてるとか、１本を繋ぎっぱで兼用してるとかおまいらどうしてる？

673 ：デフォルトの名無しさん：2009/05/23(土) 09:39:58

のののの

674 ：デフォルトの名無しさん：2009/05/23(土) 11:13:06

> 制御用の即応性と、大量のデータの転送時の速度の両方が欲しい時は、
> FTPみたいに、バッファリング無しのストリームと、バッファリングありのストリームの２本張って使い分けるのが順当かな？
> 繋ぎ直して１本でがんばって使い分けてるとか、１本を繋ぎっぱで兼用してるとかおまいらどうしてる？

HTTPで何か違うもの通してるの？

675 ：デフォルトの名無しさん：2009/05/23(土) 11:27:14

>>672
致命的に読解力が無いな。ちゃんと設定しているのに無視したら起こるだろ。

676 ：デフォルトの名無しさん：2009/05/24(日) 09:02:28

設定してなくても負荷掛けたり露骨なクロールしたら怒ると思うよ。
相手の気持ちがわからないやつだな。モテないぞ。

677 ：デフォルトの名無しさん：2009/05/24(日) 09:36:28

いやあぁっ！そんな一度に…ひぎぃぃ！！
みたいな。
そういや「ブラウザを速くする」みたいな触れ込みで
IE のセッション数の上限設定を書き換えるだけの
迷惑なツールがあったな。

678 ：デフォルトの名無しさん：2009/05/24(日) 23:20:26

robots.txtをパースすれば、童貞でも女の子にモテモテですよ。

679 ：デフォルトの名無しさん：2009/05/27(水) 10:24:04

同じIPからの接続は同時に1本までしか受け付けないようにする

680 ：デフォルトの名無しさん：2009/05/27(水) 11:33:53

NATの裏にいるユーザは我慢してね。

681 ：デフォルトの名無しさん：2009/05/28(木) 00:14:13

ゴム付きは排除され、生しか受け付けないのか。

682 ：デフォルトの名無しさん：2009/05/29(金) 18:05:02

IPってゆうな。クズ。

683 ：デフォルトの名無しさん：2009/05/29(金) 23:04:37

ImPoって呼ぶよ？

684 ：デフォルトの名無しさん：2009/06/01(月) 22:53:15

rawでsockを生成してrecvでパケットを受信するときって
どんなパケットも受信できるようになるわけじゃないよね？
特定のIPへのパケットは受け付けないのが条件か

685 ：デフォルトの名無しさん：2009/06/01(月) 23:49:00

自分以外の宛先IPでも拾えるけど?

686 ：デフォルトの名無しさん：2009/06/02(火) 00:48:28

自分宛のが拾えないんだがなんでだろう。
ブロードキャストで投げたら拾えるんだが、
他で拾えないのでいうと、ARPとかひろえないぞ。
つか、ブロードキャスト以外無理

687 ：デフォルトの名無しさん：2009/06/02(火) 01:25:36

>>686
ARPはIPじゃないぞ。

688 ：デフォルトの名無しさん：2009/06/02(火) 02:39:18

>>687
IPヘッダがないということ？
rawならIPヘッダなくても拾えるのでは

UDPで送って適当なアドレスでおくってやっても受信しなかったけどなんでだろ

689 ：デフォルトの名無しさん：2009/06/02(火) 03:20:38

>>688
当たり前だ。

ヒント:
ARP
L2スイッチ

690 ：デフォルトの名無しさん：2009/06/02(火) 03:22:03

>>688
ちなみにプラットフォームは何だ？　rawはシステム依存性が高いから
システム指定しないと会話にならんぞ。　例えばLinuxのRAWはIPしか
拾えない。

691 ：デフォルトの名無しさん：2009/06/02(火) 19:10:42

>>689
RAWを使うと何でも拾える
しかし、ARPは拾えない。何故ならIPヘッダがないから。
IPヘッダあるやつなら何でも拾えるということ？けれどrawは何でも拾える？
すみません、もう少しヒントを。

>>690
とある開発環境のライブラリを使用しています。
linuxと他のライブラリの開発環境だと、それぞれrecvするときに差がでるということですよね。

linuxのrawはIPヘッダを含むフォーマットじゃないと拾えないということですよね
IPを直接、例えば200.10.3.200のように指定して送っても拾えるということでしょうか？

692 ：デフォルトの名無しさん：2009/06/03(水) 03:45:09

IPのrawってだけじゃないの？
nicのドライバレベルのrawなら何でも拾える。
SW(L2)やL3のレベルで自分のポートに送ってくれないのは無理だけど。

693 ：デフォルトの名無しさん：2009/06/03(水) 03:55:30

nicレベルまでいかんでも、pcapライブラリ使えばおkじゃね？

694 ：デフォルトの名無しさん：2009/06/03(水) 08:08:26

rawのソケット使えば、ポートやIP関係なしに何でも受信できる？

695 ：デフォルトの名無しさん：2009/06/03(水) 11:06:28

pcapつかえば、NICに届いているパケットは全部受信できる。
届いていないパケットは受信出来ない。当たり前だ。

696 ：デフォルトの名無しさん：2009/06/03(水) 19:38:13

>>694
rawじゃIPしか駄目。IP以外はpcap使うべし。

697 ：デフォルトの名無しさん：2009/06/03(水) 22:25:40

UDPのソケット作って受信をこころみてるんだけど、受信できないのはなぜ？
bind処理はINADDR_ANYで全IPから受信、ポートは指定せず何でもOK
サーバー側が受信待ちしてる状態。サーバーのIPは設定しておらず。

そこに、クライアント側が、255.255.255.255でポートは例えば5000で送るとサーバーは受信する
けれど、100.255.255.255、100.10.255.255、100.10.25.255　だと受信されない。
クライアントのIPが100.10.25.30　だとして。

けれど、サーバー側がrawでソケットつくると
255.255.255.255はもちろん、100.255.255.255、100.10.25.255でも受信される。
100.10.255.255　これはなぜか受信されない。
rawでつくたっときはbindはしてない。

698 ：デフォルトの名無しさん：2009/06/03(水) 23:39:34

全部255ってブロードキャストアドレスじゃ…

699 ：デフォルトの名無しさん：2009/06/03(水) 23:40:34

255.255.255.255だけがなぜ受信できる？？

700 ：デフォルトの名無しさん：2009/06/03(水) 23:45:02

(ローカル)ブロードキャストアドレスになってる奴だけ受信できてるってことでFAっぽい。
つttp://www.mm-labo.com/computer/tcpip/ipaddress/broadcast.html

701 ：デフォルトの名無しさん：2009/06/03(水) 23:49:03

> サーバーのIPは設定しておらず。
ここがもんだいじゃね？

702 ：デフォルトの名無しさん：2009/06/04(木) 06:11:53

ちょっとIPの勉強して来たほうがいいと思う。
プログラム以前の問題。

703 ：デフォルトの名無しさん：2009/06/04(木) 08:05:47

>>701
設定してないのにrawでは、100.10.25.255でも受信されたのですが
サーバーも100.10.25　に属すると勝手に認識されたのでしょうか？

704 ：デフォルトの名無しさん：2009/06/04(木) 12:57:09

>>697
クライアントから出て行ってない可能性

705 ：デフォルトの名無しさん：2009/06/04(木) 13:13:54

>>703
L2でブロードキャストされたからサーバとやらまで届いた。
簡単に言うと、L2の知識が皆無なキミにはRAWソケットはまだ早いという事だ。

706 ：デフォルトの名無しさん：2009/06/04(木) 13:55:53

マイコンとかで物理層からプログラミングすれば色々勉強になるかな
速度的には厳しいけど
つまりOSが介在しない環境でというか

707 ：デフォルトの名無しさん：2009/06/04(木) 14:03:19

物理層触る必要が無ければ、知識として知ってるくらいでいい。
無線周りのデバドラとか書いてても、L3以上はあやふやな人もいるし。

708 ：デフォルトの名無しさん：2009/06/04(木) 18:23:44

ご存知の方も多いと思いますが、オンラインネットワークゲーム等でネットに繋がっている
サーバを検出するという処理があります。
その仕組みをご存知の方はないでしょうか？

サーバのポートは固定ではないので、直接見つけることはできないと思いますが良く分か
りません。サーバリストを保持するサーバが別に存在して、ゲームサーバを起動したとき
にそこに情報が登録されるとかあるのでしょうか？

709 ：デフォルトの名無しさん：2009/06/04(木) 18:29:18

> サーバリストを保持するサーバが別に存在
普通はそんな感じになってるだろうね

710 ：デフォルトの名無しさん：2009/06/05(金) 00:04:30

>>704
どうやればでていくのでしょうか？

711 ：デフォルトの名無しさん：2009/06/05(金) 00:09:12

>>705
クライアント側がUDPでおくるときに、宛先IPをブロードキャストにしておくっているけれど
L2レベルでブロードキャストの設定なんてしていないとおもうのですが
いずれのソケットも４パターンが説明できないような

712 ：デフォルトの名無しさん：2009/06/05(金) 00:22:44

>>710-711
どれをブロードキャストアドレスと認識するのかはOSによって異なる。
どういうパケットが届いているのか、L2ヘッダーまで表示してtcpdumpや
wiresharkで観察してみると良い。

713 ：デフォルトの名無しさん：2009/06/05(金) 00:33:29

>>697の記述がどこまで信用できるかってのがわからないからなぁ。
客からの問い合わせだったら「リモートログインさせてもらっていいですか？」って聞くところだ。

714 ：デフォルトの名無しさん：2009/06/05(金) 02:08:27

アープでヲレヲレって答えないと、L2SWレベルで送ってくれないと思うよ。
いいからIPの勉強してこい。プログラミングは、まだ早い。

高額のスイッチだとミラーポートみたいなのがあって、全パケット流してくれるのでそういうので見てないと分からないかもな。
鯖と蔵のケーブル直結か、スイッチじゃないハブで繋がないとなあ。
オートマだからマニュアルの操作が理解出来ない様な物だし。

715 ：デフォルトの名無しさん：2009/06/05(金) 08:06:50

UDPのソケットで全IPからの受信を許可するにはどうすればよいのでしょうか？
bindしなければいいってことでしょうか？

716 ：デフォルトの名無しさん：2009/06/05(金) 09:24:18

IPってゆうな。クズ。
connectしなけりゃどのアドレスからでも受信する。もちろんUDPだから運が悪けりゃ受信できない。

717 ：デフォルトの名無しさん：2009/06/06(土) 02:24:05

むしろUDPだと運が良ければ届くだろう。

718 ：デフォルトの名無しさん：2009/06/06(土) 12:43:14

716じゃないが、運が悪ければという表現のほうが正しいと思うのだが。
同一セグメント内を想定。

719 ：デフォルトの名無しさん：2009/06/06(土) 13:49:18

716だが、普通は運が悪くて届かない時に例外処理だな。
運が良くて届く場合を例外処理にしているプログラムは見たことが無いが、
>>717はそれが普通なのだろう。火星探査機とか?

720 ：デフォルトの名無しさん：2009/06/06(土) 22:42:13

コリジョンで消えたり、ルータが捨てたり、スイッチが捨てたりとか考慮しないから、バグで不具合出るんだよｗｗｗ

721 ：デフォルトの名無しさん：2009/06/06(土) 23:40:42

UDPで外界を目指すには

722 ：デフォルトの名無しさん：2009/06/07(日) 23:57:15

ネットワークプログラミングの初心者です。サーバプロセスが1個、クライアントプロセスが多数(10個)位で、
サーバと各クライアント間でTCPのコネクションを張ってずっと維持しながら処理を続けます。
サーバからクライアントを区別するのに、クライアントのIPアドレスとポート番号の組を使っていたのですが、
TCPコネクションが切れた後も再接続して処理を続けたいと思っています。
この場合、クライアント側にID番号などの(クライアントを識別できる)情報を持たせないと
できないでしょうか？

723 ：デフォルトの名無しさん：2009/06/08(月) 00:09:37

>>722
そのとおりだが、再接続を許さない方向で考えた方がシンプルかつ強靭。

724 ：デフォルトの名無しさん：2009/06/08(月) 01:43:57

>>723
それは仕様によると思うがなぁ。>>722がそういう要件があるということは
必要なわけで、常にｼﾝﾌﾟﾙがﾍﾞｽﾄな選択肢というわけではない。

725 ：デフォルトの名無しさん：2009/06/08(月) 08:45:55

半角カナで主張しても説得力0だな。

726 ：デフォルトの名無しさん：2009/06/08(月) 10:04:48

そこは同意

727 ：デフォルトの名無しさん：2009/06/08(月) 10:09:00

ここは2chだろ
なんかのMLと勘違いしてる白髪さんですか?

728 ：デフォルトの名無しさん：2009/06/08(月) 10:22:34

ここは2chだが、プログラム板だ。半角カナはバカの証明。

729 ：デフォルトの名無しさん：2009/06/08(月) 11:51:09

全角英数字とどっちがバカですか？

730 ：デフォルトの名無しさん：2009/06/08(月) 12:03:14

>>729
それは、女が好きなオカマと、モーホーな兄貴と、どっちが女に近いかという問題に似ている。

731 ：デフォルトの名無しさん：2009/06/08(月) 13:05:17

半角カナ嫌うのに英数字が全角じゃない男の人って

732 ：デフォルトの名無しさん：2009/06/08(月) 15:03:07

>>731
JIS 的に非常に正しいわけで。

733 ：デフォルトの名無しさん：2009/06/08(月) 18:37:29

>>732 mohtaを知らん奴発見

734 ：デフォルトの名無しさん：2009/06/08(月) 19:20:15

fjを知らない子供たち

735 ：デフォルトの名無しさん：2009/06/08(月) 20:01:06

今ならもれなくヘミネコも(ry

736 ：デフォルトの名無しさん：2009/06/09(火) 04:20:37

>>804
http://pc11.2ch.net/test/read.cgi/gamedev/1238520070/692

692 ：名前は開発中のものです。：2009/06/09(火) 00:57:34 ID:2fI/sHFo
何言ってんだ。プログラマにまともな精神持った奴がいた試しなんてねえよ。
第一プログラマと精神科なんてほとんどセットなのに今更それを語るとか情弱以下だろ。

737 ：デフォルトの名無しさん：2009/06/09(火) 08:18:36

bindですべてのIPから受信できるようにするにはどうしたらよいのでしょうか？
例えば、0.0.0.1みたいなアドレスでも受信できるようにするには

738 ：デフォルトの名無しさん：2009/06/09(火) 09:50:35

IPってゆうな。クズ。

739 ：デフォルトの名無しさん：2009/06/09(火) 10:24:13

>>737
ふつうにbindすればできる。

740 ：デフォルトの名無しさん：2009/06/09(火) 23:06:44

>>739
すみません、普通のやり方おしえてもらえないでしょうか？
特定のIPなら一般的なやり方だとはおもうのですが、全IPってのはいったい

741 ：デフォルトの名無しさん：2009/06/09(火) 23:13:09

まだIPいうか

742 ：デフォルトの名無しさん：2009/06/09(火) 23:45:24

Internet Protocolですね。わかります。

743 ：デフォルトの名無しさん：2009/06/10(水) 01:22:17

>>740
TCPなのかUDPなのか知らないが、
逆に、どうbindしたら特定のアドレスからしか接続できないようになるのか教えてほしい。

744 ：デフォルトの名無しさん：2009/06/10(水) 01:31:33

>>740
ietf行ってstd*.txt読め
それでも足らなきゃ*BSDとかLinuxのkernel読め

745 ：デフォルトの名無しさん：2009/06/10(水) 08:04:32

>>743
bindする側がIPアドレスもってない場合

746 ：デフォルトの名無しさん：2009/06/10(水) 09:43:08

IPアドレスを持っていない相手に対して、ブロードキャスト以外のIPパケットを
送ることはできない。ブロードキャストなら普通にINADDR_ANYにbindすれば拾える。

基本を知らずにRAWソケットとか使いたがる初心者が、最近増加してるのは何故?

747 ：デフォルトの名無しさん：2009/06/10(水) 09:55:59

>>746
> 基本を知らずにRAWソケットとか使いたがる初心者が、最近増加してるのは何故?

お手軽な処理系とかライブラリが増えて、ネットワークプログラムする人口が
増えているのに、基本から勉強する人口の増加率は従来通り、もしすると減少
している。

お手軽処理系とか使っている人間は、自分が使ったことのあるソフトの
機能を知ってるから「基本？なにそれ? めんどくせーW」とかいいながら
「だけど、こんなこともしてみたい」ってな、感じなのでは?

748 ：デフォルトの名無しさん：2009/06/10(水) 11:24:28

HTTPプロトコルのPUTでディレクトリをアップロードする方法ってありますか？ファイルはアップロードできるのですが。
できない場合、サーバ側にPOSTでCGI経由でディレクトリを作らせてファイルをPUTするとかが一般的でしょうか？

749 ：デフォルトの名無しさん：2009/06/10(水) 11:36:29

とあるグローバルIPアドレスが固定IPなのか動的なものなのか
わかる方法ってありますでしょうか？

750 ：デフォルトの名無しさん：2009/06/10(水) 11:54:30

まず、固定と動的の定義を考えてごらん

751 ：デフォルトの名無しさん：2009/06/10(水) 11:57:17

>>750
そんなことはどうでもいいのです。

752 ：デフォルトの名無しさん：2009/06/10(水) 12:14:29

思わせぶりな回答せずに、

そんなのねーよ。

と、スパッと回答した方がいい。

753 ：デフォルトの名無しさん：2009/06/10(水) 12:41:23

ちょっと考えればわかることをいちいち聞いてくるバカにズバっと答えるほどやさしくはないわ

754 ：デフォルトの名無しさん：2009/06/10(水) 12:45:54

>>749
なくはない。

755 ：デフォルトの名無しさん：2009/06/10(水) 12:46:23

ではなぜ今のSMTPは固定IPにしか転送しないようにできるんですか？

756 ：デフォルトの名無しさん：2009/06/10(水) 12:49:40

>>755
固定IPには転送して、固定IPには転送しない
という条件ではないはず。

757 ：デフォルトの名無しさん：2009/06/10(水) 13:09:56

>>755
そんなルールは無い。

758 ：デフォルトの名無しさん：2009/06/10(水) 13:33:28

>>748
WebDAVが使えるなら MKCOL

759 ：デフォルトの名無しさん：2009/06/10(水) 13:59:41

>>756
あれ？そうでしたっけ？
それならまあいいやｗ

760 ：デフォルトの名無しさん：2009/06/10(水) 14:39:49

>>758
ありがとう！
こんなのあったんだ。

761 ：デフォルトの名無しさん：2009/06/10(水) 17:51:47

>>755
乱暴な言い方をすれば名前とIPの関係でフィルタリングされているだけでアドレスが固定か動的割り当てかによる区別じゃない

762 ：デフォルトの名無しさん：2009/06/10(水) 18:11:04

突然スイマセン。
今簡単なhttpクライアントを作っているのですが
コンパイルはちゃんとできるのですが
必ずタイムアウトして接続できません。
何か解決策はないでしょうか？
よろしくお願いします。

763 ：デフォルトの名無しさん：2009/06/10(水) 18:43:59

エスパーさんの出番だ

764 ：デフォルトの名無しさん：2009/06/10(水) 19:30:17

タイムアウトしてるんなら、IPアドレスの指定が間違ってるとかそんなんだが、
まぁポート指定でhtonsしてないってとこじゃね？

765 ：デフォルトの名無しさん：2009/06/10(水) 23:20:56

>>746
それはつまり、bindしなくても拾えるということでしょうか？
固定IPをもっていないアドレスに対してはブロードキャストしかおくれない
よって、bindしなくてもブロードキャストしかうけつけないので
bindする必要はないということでしょうか？

766 ：デフォルトの名無しさん：2009/06/11(木) 00:07:46

IPってゆうな。クズ。

767 ：デフォルトの名無しさん：2009/06/11(木) 00:18:59

>>765
どっからそんないい加減な知識を仕入れてるんだ？

768 ：デフォルトの名無しさん：2009/06/11(木) 00:25:41

>>767
このスレからです。でもどこがおかしいのでしょうか？

769 ：デフォルトの名無しさん：2009/06/11(木) 00:55:05

自分で勉強せずに、人に聞いてばかりのやつってこんな感じになるのか。

770 ：デフォルトの名無しさん：2009/06/11(木) 01:23:44

>>768
俺はそんな事教えてない。
でも「IP」を2回使ったのでお前には二度と教えない。

771 ：デフォルトの名無しさん：2009/06/11(木) 08:06:30

>>770
でもないようを見る限りそうです

772 ：デフォルトの名無しさん：2009/06/11(木) 09:03:38

盗聴がしたいなら
http://codezine.jp/article/detail/125

773 ：デフォルトの名無しさん：2009/06/11(木) 22:33:42

inet_aton関数をユーザから入力された
IPアドレスが正しいxxx.xxx.xxx.xxxに適合しているのかに
利用して問題ないでしょうか？

774 ：デフォルトの名無しさん：2009/06/11(木) 23:03:52

775 ：デフォルトの名無しさん：2009/06/12(金) 00:28:04

ひとつのプログラムでrecvを同時に二つすることって可能？

776 ：デフォルトの名無しさん：2009/06/12(金) 00:32:43

マルチスレッドならやれる・・・！

777 ：デフォルトの名無しさん：2009/06/12(金) 00:36:58

マルチプロセスでもselectでも可能じゃね？

778 ：デフォルトの名無しさん：2009/06/12(金) 08:08:00

マルチスレッドでやるとどうなるのでしょうか？

まったく同時に二つがrecvするのでしょうか？
そのとき、処理時間は遅くなるのでしょうか？１つで受信するときとくらべて

779 ：デフォルトの名無しさん：2009/06/12(金) 08:08:27

ちょっとIP勉強してから、プログラム組もうぜｗｗｗ
世界中の端末と通信するために255.255.255.255で通信し始めそうｗｗｗ

780 ：デフォルトの名無しさん：2009/06/12(金) 08:23:53

recvって受信待ちしてるだけやろ

781 ：デフォルトの名無しさん：2009/06/12(金) 23:17:04

受信待ちしてても受信しはじめたら動くだろ

782 ：デフォルトの名無しさん：2009/06/13(土) 05:35:46

ずっと受信待ちしてたら疲れちゃうだろ。
何かパケット届いたら知らせてもらったほうが楽。

783 ：デフォルトの名無しさん：2009/06/13(土) 08:24:33

受信待ちもそれだけCPU使うのか
受信待ちと送信も同時におこなえるんだよね

784 ：デフォルトの名無しさん：2009/06/13(土) 12:09:29

受信と送信はもともと分かれてる

785 ：デフォルトの名無しさん：2009/06/13(土) 12:14:10

>>783
受信待ちになってる状態でCPUに負荷かかるOSはダメだろ。

786 ：デフォルトの名無しさん：2009/06/13(土) 12:46:37

ごめ、昔作ったマルチタスキングモニタは表スレッドからポーリングだったわ（w
割り込みルーチンから表に通知する仕組みをどう作るかで悩んでのう…

787 ：デフォルトの名無しさん：2009/06/13(土) 13:29:34

バッファとかキューとかを抱えてる
プロセスなりスレッドなりタスクなりを起こすだけやん

788 ：デフォルトの名無しさん：2009/06/13(土) 13:40:19

>>787
スレチだけど、そのキューがまさに別スレッド関連処理中で排他状態にあったら?

789 ：デフォルトの名無しさん：2009/06/13(土) 13:41:48

あ、データキューじゃなくて休眠スレッドキューの方ね。

790 ：デフォルトの名無しさん：2009/06/13(土) 13:51:26

詳細不明だが、ダブルバッファとか使えたんじゃない？

791 ：デフォルトの名無しさん：2009/06/13(土) 14:04:51

受信してるときに、送信する場合はどうなるんだ

792 ：デフォルトの名無しさん：2009/06/13(土) 14:23:21

>>791
特に問題ない。
送信(または受信)できなければ、送信(または受信)可能になるまで待たされるだけ。

793 ：デフォルトの名無しさん：2009/06/13(土) 20:39:49

>>792
それは何かのきまりでそうなってるとか？

送信優先させたい場合はどうするのだろう

794 ：デフォルトの名無しさん：2009/06/13(土) 20:43:49

たとえば

while{
recv
send
}

なるものがあったとしたら、完全に受信が終わってから、送信にうつる
そして完全に送信がおわってからまた受信する

これを別々のタスクで動作させるとなると
受信は受信で待ち受けている
送信は送信で受信がおわったら送信タスクにうつるようにする

しかし、受信が連続できて受信してる際に送信させようとなると
送信は受信が終わるのまってから、送信する

しかし、送信を優先させたい場合、受信してる最中に待たせるわけにもいかないよな

795 ：デフォルトの名無しさん：2009/06/13(土) 20:50:14

送受信は普通独立させるだろJK
受信無しに送信したい時どうすんだよ

796 ：デフォルトの名無しさん：2009/06/14(日) 00:15:15

独立させても、受信と送信を同時にはできないでしょ
OSがあったらできるか　なかったらできない

797 ：デフォルトの名無しさん：2009/06/14(日) 12:06:57

recv呼び出しとsend呼び出しを同時にはできるでしょ
送受信が同時に行われるかどうかは知らんけど

ところでrecv!=受信 send!=送信だよね
基本的なことだけど・・・

798 ：デフォルトの名無しさん：2009/06/14(日) 13:58:12

いまだにポーリングしまくってるドライバなネットワークデバイスも有るしな。
普通はハンドシェークするプロトコルにするから、受信が無いと送信は出来ない。

799 ：デフォルトの名無しさん：2009/06/14(日) 23:24:04

>>798
> 普通はハンドシェークするプロトコルにするから、受信が無いと送信は出来ない。

送受信は独立にするだろJK^2

受信はメタな意味でイベントに属して、送信は処理に属
する、全く別の概念。

それと 3-way ハンドシェイクをもう一辺勉強し直せ。
TCP は双方同時送信から始まっても一本のコネクション
になるように設計されてる。

800 ：デフォルトの名無しさん：2009/06/15(月) 00:56:05

そういう意味のハンドシェークじゃ無いと思うぞ。例えばSMTPとか。

801 ：デフォルトの名無しさん：2009/06/15(月) 01:03:43

そういう意味ならプロトコル上でメッセージをピンポン
するからといって、プログラムをその通りに（～を受
信／～を送信／～を受信…）書くのは頭悪すぎだろ。

802 ：デフォルトの名無しさん：2009/06/15(月) 05:27:36

プログラムとは手順を記述する事だから手順通りに書くのは基本。
おまいのプログラム見にくいって良く言われるだろうｗｗｗ

803 ：デフォルトの名無しさん：2009/06/15(月) 06:42:08

別に俺の専売特許じゃねーよ。

http://ja.wikipedia.org/wiki/%E6%9C%89%E9%99%90%E3%82%AA%E3%83%BC%E3%83%88%E3%83%9E%E3%83%88%E3%83%B3
http://en.wikipedia.org/wiki/Event_driven_finite_state_machine

まぁ俺なら switch じゃなくてテーブル引きにするがな。
デザパタ的に言えばコマンドパターンとかもこれだろ。

804 ：デフォルトの名無しさん：2009/06/15(月) 07:50:54

>>802
手順で想定した通りの入力があるとは限らないわけで。
状態遷移を使った実装にしないと、すぐに破綻しないか？

805 ：デフォルトの名無しさん：2009/06/15(月) 08:21:48

送受信独立させても、受信中には送信送信処理できないだろ

受信→送信　ならできるが

受信１→受信２→送信１　になってしまうこともありうるのでは

806 ：デフォルトの名無しさん：2009/06/15(月) 08:28:37

なんで受信が先にある前提なんだ？
そもそも
> 受信が無いと送信は出来ない。
こんな条件があったら通信できないじゃないか。

807 ：デフォルトの名無しさん：2009/06/15(月) 08:39:40

受信があれば送信できるだろ。

808 ：デフォルトの名無しさん：2009/06/15(月) 08:45:48

>>805
> 送受信独立させても、受信中には送信送信処理できないだろ
そう言われても、どのレベルでの話なのか分からないな。
物理層の話なのか、ソケットAPIレベルの話なのか、アプリケーションレベルの話なのか
はっきりさせてほしい。

809 ：デフォルトの名無しさん：2009/06/15(月) 23:37:50

仮にデータを受信したら送信すると仮定して

受信→送信、受信→送信という流れであるはずが

受信→受信→送信　というタイミングになってしまった場合はどうなるんだ

受信して、送信にうつろうとするが、うつろうとしてる最中に次のデータを受信している最中になってしまうとか
その場合、いったん受信のほうに処理がうつるわけですよね

810 ：デフォルトの名無しさん：2009/06/15(月) 23:52:11

> 受信→受信→送信　というタイミングになってしまった場合はどうなるんだ
どんなタイミングでデータを受信してもきちんと動くようにすればいい。
というか、そうすべき。

811 ：デフォルトの名無しさん：2009/06/15(月) 23:53:14

>>809
シングルスレッドの同期通信しか考えられない人？

812 ：デフォルトの名無しさん：2009/06/16(火) 00:06:14

シングルスレッドしか出来ない環境だと？
シングルじゃなければ、同一のソケット宛でも別扱いになるのか

813 ：デフォルトの名無しさん：2009/06/16(火) 00:11:45

>>812
つselect

814 ：デフォルトの名無しさん：2009/06/16(火) 03:29:09

プロトコルだから手順通りに来ないのはエラーを返すべき。
SMTPでHELO来る前にMAIL FROM来たら、504でreject返してぶち切っていいだろ。
鯖側は基本受信待ち。話しかけられるまで沈黙を守るべき。

815 ：デフォルトの名無しさん：2009/06/16(火) 07:42:58

一般論では分が悪いので、個別の事例に逃げ込んだわけですね。

816 ：デフォルトの名無しさん：2009/06/16(火) 08:09:16

>>813
詳しくお願いします

817 ：デフォルトの名無しさん：2009/06/16(火) 09:43:21

具体例出されると都合でも悪いのか？

818 ：デフォルトの名無しさん：2009/06/16(火) 09:48:12

具体例出すのはいいんだけど、
プロトコルの設計と、プログラムの設計がごっちゃになってるような気がする。

819 ：デフォルトの名無しさん：2009/06/16(火) 13:31:17

>>809
HTTPのパイプライニングって知らない?

820 ：デフォルトの名無しさん：2009/06/16(火) 21:18:59

質問してるやつ、レス番名前に入れてくれ。　ごっちゃな話しが本人がごっちゃなのか
レスがごっちゃなのか判らんw

821 ：デフォルトの名無しさん：2009/06/16(火) 22:06:34

>>816
select使える環境なら、大抵スレッド使えるだろ。
組み込みOSとか、携帯アプリとかの特殊な環境なら
環境の説明がないと有意義なレスはつかないと思うよ。

822 ：デフォルトの名無しさん：2009/06/16(火) 22:22:18

受信のスレッドと送信のスレッドがあるとして
スレッドを別々にするなら、どのタイミングで送信スレッドにうつるようにすればいいの？

受信は受信で処理
送信は送信で処理　それぞれ独立するとして

823 ：デフォルトの名無しさん：2009/06/16(火) 22:26:58

普通のスレッドなら勝手にスイッチするだろう

824 ：デフォルトの名無しさん：2009/06/16(火) 22:45:24

勝手にスイッチって
受信完了→送信→受信待ち　って流れ？
受信完了→受信待ち→受信完了→送信　って風にはならないの？
超高速で受信がきたとして

825 ：デフォルトの名無しさん：2009/06/16(火) 23:22:17

受信、送信も処理的にはウエイトなんだけど
そこで切り替わるかもしれないし、しないかもしれないし誰にもわからない
マルチCPU（コア）環境なら本当に同時に動くかもしれない

826 ：デフォルトの名無しさん：2009/06/16(火) 23:43:42

>>824
スレッド使ったネットワークプログラムのソースくらいその辺に転がってるから
まずはそれ読んで感覚を掴んだ方がいい。
あと、UNIXネットワークプログラミングでも、スレッド使った例があったはず。

827 ：デフォルトの名無しさん：2009/06/17(水) 00:00:12

>>824
受信したものに対して応答を返す場合には、受信スレッドで応答を送信する形式が多いんじゃないかな。

828 ：デフォルトの名無しさん：2009/06/17(水) 00:04:56

>>824
TCPは全二重通信だということを理解してくれ。
つまり送信と受信は同時にできるのだ。

829 ：デフォルトの名無しさん：2009/06/17(水) 02:04:06

厳密には同時には無理。ACKとか返して始めて通信が成立するから。
相手の状況なんて確認せずに送りつけてるだけじゃ、あっさり捨てられて無駄なパケット送る事に成るだけ。

830 ：デフォルトの名無しさん：2009/06/17(水) 07:58:58

>>829
アホは消えろ

831 ：デフォルトの名無しさん：2009/06/17(水) 09:22:20

>>829
キミ、周回遅れ。引っ込んでなよ。

832 ：デフォルトの名無しさん：2009/06/17(水) 11:35:00

超高速でレスポンセ返ってきたとしとも、
ソケットに届いたデータは取り出されるかソケットが閉じられるまで残っとるはずだから、
ゆっくらスイッチングすれば良いんじやないの。

833 ：デフォルトの名無しさん：2009/06/17(水) 23:45:41

>>828
すみません。ＵＤＰの話です。

受信と送信が独立してるならこの場合どうなるんだろう

834 ：デフォルトの名無しさん：2009/06/18(木) 00:02:27

受信は常にwhileというイメージはあるが
送信はwhileしてても待ち受けてるわけじゃないからな

835 ：デフォルトの名無しさん：2009/06/18(木) 00:41:30

>>833
独立してるんなら、独立に送信して受信するだけだろ。
何が疑問なのかさっぱり伝わってこない。

836 ：デフォルトの名無しさん：2009/06/18(木) 00:51:33

UDPはいわば自分でそういったプロトコルを決めるものだから
できるかどうかはアプリケーション側の責任

837 ：デフォルトの名無しさん：2009/06/18(木) 02:29:40

>>833
UDPも全二重

838 ：デフォルトの名無しさん：2009/06/18(木) 11:45:21

今時半二重なんて糸電話くらいだろ…

839 ：デフォルトの名無しさん：2009/06/18(木) 11:48:44

こちらXXです、どうぞ。

840 ：デフォルトの名無しさん：2009/06/18(木) 11:50:45

今時っていえば新規開発でfork使ってる人っている？

841 ：デフォルトの名無しさん：2009/06/18(木) 11:51:12

それは「日本沈没」のシーンを思い出すな

842 ：デフォルトの名無しさん：2009/06/18(木) 12:42:36

糸電話を全二重に改良してみてはどうかな

843 ：デフォルトの名無しさん：2009/06/18(木) 13:14:09

糸電話は人の使い型が半二重なだけでデバイス的には全二重だろ。
バケツくらいの大きさの糸電話なら普通に話しながら聞ける。

844 ：デフォルトの名無しさん：2009/06/18(木) 15:55:09

>>843
>デバイス的には全二重だろ。
相手の声に対して逆位相の波形流したら
相殺すると思うんだが。

845 ：デフォルトの名無しさん：2009/06/18(木) 15:56:26

たすけてー
アッーーーーー！

IE6までって、ブラウザ2つ立ち上げるとそれぞれ別セッションになったけど、
IE8って同じセッションになっちゃう？？？

IE6では2つのブラウザで同時操作しても遷移チェックOKだったけど、
IE8だと遷移エラーになる・・・。
困った。
IE6と同じ振る舞いにできないものか。

846 ：デフォルトの名無しさん：2009/06/18(木) 16:08:39

つ[SessionMerging]

847 ：デフォルトの名無しさん：2009/06/18(木) 16:09:05

>>838
無線LANは半二重だろ。

848 ：デフォルトの名無しさん：2009/06/18(木) 16:29:05

>>844
>>デバイス的には全二重だろ。
>相手の声に対して逆位相の波形流したら
>相殺する

なるほど、と思ったが更に押し進めて逆位相をオフセット
として信号を重畳すれば全二重になるな。面白い。

849 ：デフォルトの名無しさん：2009/06/18(木) 17:01:39

>>844
波がぶつかった通信経路中の一点でのみ相殺するだけだろ

850 ：デフォルトの名無しさん：2009/06/18(木) 17:41:44

糸電話って粗密波(縦波)伝導なのか　糸の揺れる波（横波）伝導なのか?

851 ：デフォルトの名無しさん：2009/06/18(木) 18:07:08

>>848
> 逆位相をオフセットとして信号を重畳

逆だな。つまり自分自身が送出した信号を（時間遅延を
考慮して）入力から引くんだ。確かエコーキャンセラの
仕組みがそうだ。

852 ：デフォルトの名無しさん：2009/06/18(木) 23:01:08

recvで受信中に次のデータが超高速できた場合、あとにきたやつは破棄されるの？

853 ：デフォルトの名無しさん：2009/06/18(木) 23:07:31

どのレイヤーのことを話しているのかはっきりしないとグダグダ

854 ：デフォルトの名無しさん：2009/06/18(木) 23:26:43

ネットの仕組みがよく分からん奴は、23:30からNHK教育のITホワイトボックス見とけ。

855 ：デフォルトの名無しさん：2009/06/18(木) 23:38:51

>村井純　森下千里
なんだこの組み合わせｗ

856 ：デフォルトの名無しさん：2009/06/18(木) 23:42:57

>>850
縦波。　糸を角に引っ掛けて方向を変えても音が伝わるって実験やったな。

857 ：デフォルトの名無しさん：2009/06/18(木) 23:57:35

>>852
ぶっちゃけると、あるじっそうではりんぐばっふぁになってます
あとは、わかるよな

858 ：デフォルトの名無しさん：2009/06/19(金) 00:53:54

だからちゃんと受信処理やるまえに、送信が来て溢れると捨てられる。
最初に受信処理が正しい。

859 ：デフォルトの名無しさん：2009/06/19(金) 01:01:47

>>858
お前が言っているのは「画面出力前にキー入力すべき」っ
ていうのと一緒で全然一般的じゃない。

860 ：デフォルトの名無しさん：2009/06/19(金) 06:02:27

つバッファオーバフロー

861 ：デフォルトの名無しさん：2009/06/19(金) 08:26:03

バッファーオーバフローするようなクソプログラムを書くんじゃない

862 ：デフォルトの名無しさん：2009/06/19(金) 08:58:37

|イデオン - 禁断の惑星| >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> |エヴァ - イデオン|

863 ：デフォルトの名無しさん：2009/06/19(金) 10:50:52

>>857
もう少しヒントを

864 ：デフォルトの名無しさん：2009/06/19(金) 11:37:57

>>863
バッファは有限なのだから、その容量を超えるデータを詰め込めるわけ無いだろ。

865 ：デフォルトの名無しさん：2009/06/19(金) 12:56:13

リングバッファにして上書きを許せばいくらでもデータを詰め込めるよ！
上書きされるけど

866 ：デフォルトの名無しさん：2009/06/19(金) 13:10:40

>>865
リングバッファじゃなくても古いの廃棄すればいくらでも詰め込めるわけだが。
そういう話じゃないのがわからないのか?

そもそも、TCPだと上書きじゃ無くて入らなければ破棄だぞ。
UDPだって大抵はそういう実装だ。

867 ：デフォルトの名無しさん：2009/06/19(金) 13:40:22

ストリームで送られてくるので上書き出来るなら、任意のプログラム送り込みまくりだろう。

リングとは逝っても長方形状のメモリ素子を循環利用してるに過ぎないが。

868 ：デフォルトの名無しさん：2009/06/19(金) 13:46:57

>リングとは逝っても長方形状のメモリ素子を循環利用してるに過ぎないが。
何を言っているのかよく解らんが
リニアなメモリ空間の一部を使用しているという意味なら
態々言うまでもない。

>>866
>TCPだと上書きじゃ無くて入らなければ破棄だぞ。
送信元に「受け取ったよー！」つっといて
内部で破壊しちゃったら詐欺だよなあ。

869 ：デフォルトの名無しさん：2009/06/19(金) 13:56:42

リングバッファではあふれたアドレスは単純に無視される。
トポロジー的にはリング。

870 ：デフォルトの名無しさん：2009/06/19(金) 15:45:58

>>866
>そもそも、TCPだと上書きじゃ無くて入らなければ破棄だぞ。
入らなかったらwindowを閉じる。

871 ：デフォルトの名無しさん：2009/06/19(金) 18:46:11

そもそもwindowがあるから受信不可なデータは来ないんじゃね?

872 ：デフォルトの名無しさん：2009/06/19(金) 19:09:55

通信プログラムでは、相手がこっちの期待したとおりに動くと仮定するなってのが鉄則。

873 ：デフォルトの名無しさん：2009/06/19(金) 19:17:56

>>872
そもそもTCPは受信window外のメッセージを処理したら駄目なんじゃね?
てゆーかRFC位読んどけよ…

874 ：デフォルトの名無しさん：2009/06/19(金) 20:51:28

処理しちゃダメって決まってればそれ以上のパケット送ってこない
なんてことはない。

875 ：デフォルトの名無しさん：2009/06/19(金) 21:11:35

>>874
はぁ?データがユーザアプリ層まで来ねぇって言ってんだけど。
それとも手前はライブラリが仕様通りに動かない可能性まで考慮してるっつーのか。
頭めでてー奴だな。

876 ：デフォルトの名無しさん：2009/06/19(金) 21:15:08

だからレイヤーをはっきりと(ry

877 ：デフォルトの名無しさん：2009/06/19(金) 21:34:37

linuxでrecv()するのに最初にサイズの4byteを拾ってから次にサイズ分のrecv()を呼んでるですが
こういう呼び方をするとwindowは小さくなってしまうのでしょうか?

878 ：デフォルトの名無しさん：2009/06/19(金) 22:03:44

windowとかもっと下のレイヤーだから関係ない
好きな長さで拾っておｋ

879 ：デフォルトの名無しさん：2009/06/19(金) 22:09:48

もっと下つーかTCP/IPの場合1個下か
データに何が入ってようと関係なく
recvで帰ってきた長さのデータを保証するだけ

880 ：デフォルトの名無しさん：2009/06/19(金) 22:26:45

>>878
気にしないで良いみたいで安心しました。
RCVBUFの残りで変化すると想像してます。

別の質問なんですけど、epollでETを指定した場合で立ち下がりにも反応するのでしょうか?
あとEPOLLOUT+EPOLLETで常にトリガが来る様な気がするんですがそういう物でしょうか?

881 ：デフォルトの名無しさん：2009/06/19(金) 23:14:29

linuxなら想像すんじゃなくてソース読めよ

882 ：デフォルトの名無しさん：2009/06/19(金) 23:21:01

linuxだからソース読むより想像した方がいい。

883 ：デフォルトの名無しさん：2009/06/20(土) 02:44:33

>>876
> だからレイヤーをはっきりと(ry

別にライブラリの内側だってバッファがある分だけ
window切ってそれ以外無視するんだから同じ話だけどな。

884 ：デフォルトの名無しさん：2009/06/20(土) 08:55:14

linuxのsocketとか、どこの学習用糞ソース使われてるのやらｗｗｗ

ACK無視して速度出ると多めに送ってくる相手も居れば、途中で廃棄されて全然届かないのも有るのがネットの世界。
あとは不正アクセス目的で不正パケット送ってくる香具師も居る。

885 ：デフォルトの名無しさん：2009/06/20(土) 09:41:05

通常：受信→送信
超高速：受信１→受信２→送信２　（送信１は受信２に上書きされてしまって消える）

超高速の場合を回避するようにしたいとなるとどうプログラムかけばいいのでしょうか？

ただし、通常と超高速が混在しているものとして

886 ：デフォルトの名無しさん：2009/06/20(土) 10:02:35

>>884
> ACK無視して速度出る

どこのアホスタックだそれは。遅くなることはあっても
早くなることはないぞ。

887 ：デフォルトの名無しさん：2009/06/20(土) 11:11:04

ソース読めば一発でわかることを長々と…

888 ：デフォルトの名無しさん：2009/06/20(土) 11:12:41

http://tools.ietf.org/html/rfc793

windowに収まらないセグメントはRSTでなければACKを返
送して、何れにせよdropすることになってる。

> If an incoming segment is not acceptable, an acknowledgment
> should be sent in reply (unless the RST bit is set, if so drop
> the segment and return):
>
> <SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>
>
> After sending the acknowledgment, drop the unacceptable segment
> and return.
>
> In the following it is assumed that the segment is the idealized
> segment that begins at RCV.NXT and does not exceed the window.

これは攻撃がどうのとか受信バッファがどうのというよ
りも主に過去の別セッションのセグメントを拾わない為
の措置なのでこれを守ってないスタックは送信側だろう
が受信側だろうがアホスタックと呼ばれても仕方ない。

889 ：デフォルトの名無しさん：2009/06/20(土) 20:20:45

>>886
delayed ackならack待たないでしょ。
TCP加速機の類いは、伝送遅延を克服するために、
積極的にackを無視する。

890 ：デフォルトの名無しさん：2009/06/20(土) 21:45:34

>>885
ＵＤＰでは無理

891 ：デフォルトの名無しさん：2009/06/21(日) 08:57:16

アクセラとか届いてないのにACK返して自分のバッファでごにょごにょするのとか間のネットに入れられたりするしなあ。
いまやなんでもありだし、そういう場合を想定して実装するべき。
他所は動くのに、こちらのだけうまく動かないと言われて立場が悪くなるだけ。

892 ：デフォルトの名無しさん：2009/06/21(日) 12:57:26

>>891
アホは書き込むな

893 ：デフォルトの名無しさん：2009/06/22(月) 11:47:37

>>889
> delayed ackならack待たないでしょ。

遅延ACKはACK返す回数を減らして間引く話だよ。
Silly Window Syndrome でぐぐったら出てくる。
決してwindowを無視する話じゃない。

894 ：デフォルトの名無しさん：2009/06/22(月) 12:34:14

もしかして、ここにいる連中は rfc も読まずに憶測とか腐ったような
解説本から得た知識だけで、えらそなこと書いてるのか？

895 ：デフォルトの名無しさん：2009/06/22(月) 13:29:04

>>894
この辺の話はrfcの何番を読めばいいですか？

896 ：デフォルトの名無しさん：2009/06/22(月) 13:43:04

std5.txt == rfc791.txt IP
std6.txt == rfc768.txt UDP
std7.txt == rfc793.txt TCP

897 ：デフォルトの名無しさん：2009/06/22(月) 15:14:15

これも追加しといて。

http://tools.ietf.org/html/rfc879
> The TCP Maximum Segment Size and Related Topics

http://tools.ietf.org/html/rfc1122
> Requirements for Internet Hosts -- Communication Layers

http://tools.ietf.org/html/rfc1123
> Requirements for Internet Hosts -- Application and Support

898 ：デフォルトの名無しさん：2009/06/22(月) 15:29:15

個人的には Winsock に関する技術文書は良く書かれて
いると思うんだ（後発だからか？）

↓の該当部分は RFC より取っつきやすいと思う。
http://www.kt.rim.or.jp/~ksk/wskfaq-ja/intermediate.html
> 3.16 - Nagle アルゴリズムとは何ですか?
> 3.17 - Nagle アルゴリズムをオフにすべきなのはどんなときでしょう?
> 3.18 - TCP の移動ウィンドウとは何ですか?
> 3.19 - お馬鹿なウィンドウ症候群(silly window syndrome)とは何ですか?
> 3.20 - 遅延 ACK アルゴリズムとは何ですか?

899 ：デフォルトの名無しさん：2009/06/22(月) 16:49:11

>>898
winsock に特化した内容が、あたかも汎用性があるみたいな書き方で
書かれてることがあるから、別のプラットフォームに行ったときに
痛い目見たりするけどな…

900 ：デフォルトの名無しさん：2009/06/22(月) 19:58:39

上の rfc をテンプレに入れるべきなのでは？？？

901 ：デフォルトの名無しさん：2009/06/22(月) 20:12:19

winsockほど糞なものは探すのが難しい

902 ：デフォルトの名無しさん：2009/06/23(火) 04:42:17

http://www.kt.rim.or.jp/~ksk/wskfaq-ja/examples/rawping.html

このpingのソースなんですけどrecvしたパケットの
IPヘッダのチェックサムもICMPヘッダのチェックサムも計算してないですけど
壊れてる可能性は無いのでしょうか？

903 ：デフォルトの名無しさん：2009/06/23(火) 05:11:33

>>902
普通, check sum 間違ってたらProtocol Stack側が廃棄処分するので
ユーザの手元まで届かない

904 ：デフォルトの名無しさん：2009/06/23(火) 22:19:37

WinsockでNAT越えするためのサンプルプログラム等ありましたら教えてください

905 ：デフォルトの名無しさん：2009/06/23(火) 23:24:33

俺も>>904のサンプルプログラム欲しい！めっちゃ欲しい！

906 ：デフォルトの名無しさん：2009/06/24(水) 00:10:46

普通に送受信すれば、よっぽどアホなNATじゃないかぎり大丈夫。

907 ：デフォルトの名無しさん：2009/06/24(水) 01:33:19

>>906
何が大丈夫なのですか？

908 ：デフォルトの名無しさん：2009/06/24(水) 02:07:58

そもそも何が大丈夫じゃないと思ってるんだ？

909 ：デフォルトの名無しさん：2009/06/24(水) 02:24:26

>>906
普通に送受信とはなんですか？

910 ：デフォルトの名無しさん：2009/06/24(水) 10:25:12

何をしたらどうなって同困ってるんだよ

911 ：デフォルトの名無しさん：2009/06/24(水) 12:10:23

>>910
困っているのはサンプルプログラムが見つからないこと

912 ：デフォルトの名無しさん：2009/06/24(水) 12:17:53

いやNAT超えで困ってるなら、そもそもNAT越えられないとやらのプログラムはあるんじゃないの？

913 ：デフォルトの名無しさん：2009/06/24(水) 13:29:31

>>912
あなたは勘違いしています。

914 ：デフォルトの名無しさん：2009/06/24(水) 13:47:46

NATの所為で通信できない、というシチュエーションは幾つかあるだろうが
それら全部をひっくるめて「NAT越え」と表現するような奴だから
自分が何をしたいのかすら解ってないかも知れない。

915 ：デフォルトの名無しさん：2009/06/24(水) 13:53:31

>>914
解らずともソースコードを追って学ぶ姿勢なのが私です

916 ：デフォルトの名無しさん：2009/06/24(水) 13:59:27

winsock nat traverseで検索すれば見つかるだろ。中は見てないが。
http://www.codeproject.com/KB/IP/PortForward.aspx?fid=275054&df=90&mpp=25&noise=3&sort=Position&view=Quick&fr=26

917 ：デフォルトの名無しさん：2009/06/24(水) 14:05:17

次はたぶん「UPnPってどうやるんですか？」だろうな。

918 ：デフォルトの名無しさん：2009/06/24(水) 15:20:57

>>917
それはググればわかりますよ。

919 ：デフォルトの名無しさん：2009/06/24(水) 17:43:10

>>917
どうやってやるのか、ってソースコードを見ればわかります。

920 ：デフォルトの名無しさん：2009/06/24(水) 19:44:09

>>919
なあ…面白いか？

921 ：デフォルトの名無しさん：2009/06/24(水) 19:46:34

>>920
あなた面白いですね

922 ：デフォルトの名無しさん：2009/06/25(木) 06:20:30

むしろNATよりもUPnPで外と通信するほうが大事。

rfcが完全に守られてる訳でもないし。ネットワーク的に革新的な装置のほとんどはrfcにない特殊な通信でパフォーマンス稼いでたりする。
rfcも後追いで、先進的な仕様を盛り込まずに実績重視な所も有るからね。実績出るまではrfcに反映されない闇規格黙認の悪循環。

923 ：デフォルトの名無しさん：2009/06/25(木) 09:08:39

>>922
blogでやれ。

924 ：デフォルトの名無しさん：2009/06/25(木) 14:24:42

つーか雑談スレあるぞ

ネットワークプログラミング雑談
http://pc12.2ch.net/test/read.cgi/tech/1235800707/

925 ：デフォルトの名無しさん：2009/06/28(日) 17:18:59

ちょっと相談なんですけれど、
64キロバイトほどのデータを定期的にEthernetのLAN内のマシン一台にリアルタイムに送信するプログラムを書いているのですが、
発信から到着までどうしても1秒ほどのラグが出てしまうのです。
遅延を100ミリ秒以下に抑えたいのですが(遅延をなるべく小さくしたい)、
こういう場合によく使われるテクニックを教えていただけないでしょうか。

また、遅延が起こる原因として考えられそうなことも教えていただければ幸いです。

926 ：デフォルトの名無しさん：2009/06/28(日) 17:20:25

TCPでつないでやってるの？

UDPで投げるようにしてみるとか。

927 ：デフォルトの名無しさん：2009/06/28(日) 18:56:53

リアルタイムは無理だろう。
全部のノードをリアルタイムOSに変更して、スパコンに使われる様な高帯域/低遅延ネットワークのハードを導入するしか。
普通のスイッチングハブなんて経由したら普通に遅延するよ。

http://pc12.2ch.net/test/read.cgi/tech/1102483474/
OpenMPプログラミング
http://pc11.2ch.net/test/read.cgi/os/969972176/
出たよーQNX Realtime Platform！！
http://pc11.2ch.net/test/read.cgi/os/1006784236/
分散ＯＳ
http://pc11.2ch.net/test/read.cgi/hard/1245859735/
【スパコン】スーパーコンピュータ関連情報2【HPC】

928 ：デフォルトの名無しさん：2009/06/28(日) 19:28:58

> 発信から到着までどうしても1秒ほどのラグが出てしまうのです。
これは異常。100msは楽勝でクリアできなければおかしい。
ボトルネックになってるところがあるはず。名前解決とか。

929 ：デフォルトの名無しさん：2009/06/28(日) 19:35:20

実際に送受信されてるパケットをキャプチャして、
発信側の処理が遅いのか、受信側の処理が遅いのかを特定すべし。

930 ：デフォルトの名無しさん：2009/06/28(日) 20:01:13

パケ分割して生成とか

931 ：デフォルトの名無しさん：2009/06/28(日) 20:29:46

そもそも隣で1Gbpsでnyしてる様なLANかもだし、何とも言えない。

932 ：デフォルトの名無しさん：2009/06/28(日) 23:09:04

pingうったらＴＴＬはいくつになる？

933 ：デフォルトの名無しさん：2009/06/29(月) 00:58:27

>>925
>>926の言うようにTCPなら、
> 3.16 - Nagle アルゴリズムとは何ですか?
を読め。

934 ：デフォルトの名無しさん：2009/07/01(水) 22:52:37

udp上で使えるtelnetのようなプロトコルはありませんか？
tcpは環境の都合で使えません

935 ：デフォルトの名無しさん：2009/07/01(水) 22:56:36

UDP の上に IP をのっけちゃうか、かなぁ
IP over UDP とか、TCP over UDP で検索すると何件かかかるみたいだけど、
お望みの解決に近づけるものがあるかどうかはわからない。

936 ：デフォルトの名無しさん：2009/07/01(水) 23:02:38

udpの時点で使いものに成らないと(ry
tcpが駄目ならudpはもっと無理だと(ry

937 ：デフォルトの名無しさん：2009/07/01(水) 23:38:07

UDPを複数使って、ハンドシェーク

938 ：デフォルトの名無しさん：2009/07/01(水) 23:45:29

どうやら既存のプロトコルとしては無さそうですね
まあぶっちゃけ特定ポート垂れ流しレベルでいいんで・・

939 ：デフォルトの名無しさん：2009/07/01(水) 23:50:31

到達性とかを保証するのがTCPで、
UDPは到達性の保証がないわけで、
垂れ流しじゃTCP相当のものは実現できない。

940 ：デフォルトの名無しさん：2009/07/02(木) 00:45:39

>>934
udpは使えるがtcpは使えないってどういう環境の都合？　

941 ：デフォルトの名無しさん：2009/07/02(木) 00:50:19

使用してる環境と要求によるな。
ちょっとくらい取りこぼしてもいいんなら、単純な垂れ流しで十分。

942 ：デフォルトの名無しさん：2009/07/02(木) 01:37:32

UDPは「ちょっとくらい」を保証できない。
全部取りこぼしてもいいなら単純な垂れ流しで十分だが。w

943 ：デフォルトの名無しさん：2009/07/02(木) 02:55:47

UDPって順番の逆転とかあるんだっけ？
それが無いと保証があればちょっとはラクなんだが

944 ：デフォルトの名無しさん：2009/07/02(木) 03:05:00

逆転あるよ。

945 ：デフォルトの名無しさん：2009/07/02(木) 03:07:13

番号振れば問題ないよ

946 ：デフォルトの名無しさん：2009/07/02(木) 06:24:15

前から思ってたんだけど TCP over UDP って需要ありそうな気がするんだ。

947 ：デフォルトの名無しさん：2009/07/02(木) 06:29:33

番号振っても届かなきゃなあ。
再送求めて、DoSアタック騒ぎに成るのがヲチ。

何のために？
プロトコル番号を、tcp(6)じゃなくてudp(17)にすればほぼ同じでしょ。
問題はそんな変な事してもまともに使えないってこと。

948 ：デフォルトの名無しさん：2009/07/02(木) 06:34:57

>>946
同じ階層にoverってどういうことｗ

949 ：デフォルトの名無しさん：2009/07/02(木) 08:09:13

>>948
TCPのペイロードに、UDPヘッダつきのデータ流すんだろ。

950 ：デフォルトの名無しさん：2009/07/02(木) 08:54:36

>>948
ほかにもSSHoverHTTPとか言いたいことは分かるけど気分悪いよね。

951 ：デフォルトの名無しさん：2009/07/02(木) 10:42:10

IPをUDPにカプセル化すればそこから先は、ユーザランドで好き勝手に出来る。
以前、IP over UDP over SSH over socksで穴開けていたことがあるが、結構使えた。

952 ：デフォルトの名無しさん：2009/07/02(木) 12:10:39

需要があるから実際 IP over UDP とか TCP over UDP を検索すると
あれこれ出てくるんじゃないか。

953 ：デフォルトの名無しさん：2009/07/02(木) 12:15:57

IP over UDPは作ったことあるな。

954 ：デフォルトの名無しさん：2009/07/02(木) 14:01:53

垂れ流しで作ってみたけど、
IPが振られるまで使えないことが今更問題だとわかった
やっぱシリアルのがいいか・・・

955 ：デフォルトの名無しさん：2009/07/02(木) 14:44:20

IPが振られる？

956 ：デフォルトの名無しさん：2009/07/02(木) 15:00:22

DHCP?

957 ：デフォルトの名無しさん：2009/07/03(金) 00:53:04

>>950
そんな程度のことで気分悪くなるなよ

958 ：デフォルトの名無しさん：2009/07/03(金) 00:53:52

何か変な事をやろうとしてる悪寒。

959 ：デフォルトの名無しさん：2009/07/03(金) 01:10:27

沈黙は金

960 ：デフォルトの名無しさん：2009/07/03(金) 04:41:01

沈黙はtimeout

961 ：デフォルトの名無しさん：2009/07/03(金) 08:51:03

再送も無しか。NATタイマが短気で遮断されてるのかもだが。

962 ：デフォルトの名無しさん：2009/07/03(金) 16:31:26

>>948
UDP は hole punching とかあるじゃん。その上で TCP 通す。
でも確かに IP 通した方が便利だね。デバイスドライバにして
OS から NIC I/F みたいに見えるのがいいと思う。

>>949
逆だ逆。

963 ：デフォルトの名無しさん：2009/07/03(金) 17:35:00

UDPで正確にデータ通信する方法を考えてみました。
添削お願いします。

■A→Bへの転送
Aは基本的にBの反応(ACK)を伺いながら通し番号付きデータを
一方的に送りつける。BのACKを待たず一度に送りつける量は、
Bの許容範囲内(ウィンドウ)にする。
もしBから何かの番号のACKが届けば、その番号までのデータは
届いたと判断し、ウィンドウをずらして転送を続行する。
受け取り通知のない番号以降のデータはタイムアウトを取り、
それが過ぎたら通知済の番号直後からデータを再送する。

Bは、Aの送信を受け続けながら、届いた番号データをまとめ、
連続する部分までの番号付きのACKを、ある間隔ごとに返す。
その間隔はAのタイムアウト以内である事。
また、ウィンドウ範囲を満たしていれば速やかにACKを返す事。
もしも番号が連続しないことを検出したら連続する時点の
ACKを返し、Bの再送まで待つ。
(つづく)

964 ：デフォルトの名無しさん：2009/07/03(金) 17:36:26

例) Bのウィンドウ8として10個のデータ送る。
A　　　　B
|----->| 01
|----->| 02
|----->| 03
|----->| 04
|----->| 05
|<-----| 02 02まで届いたと返事
|　　　　 | A、ウィンドウ += 2
|----->| 06
|----->| 07
|----->| 08
|----->| 09
|----->| 10 Bのウィンドウ範囲(10-2=8)なので待機
|　　　　 | Bが反応なし(03がタイムアウト)
|----->| 03 再送
|----->| 04
|----->| 05
|<-----| 05 05まで届いたと返事
|----->| 06
|----->| 07
|--> X　| 08 パケットロス
|<-----| 07 07まで届いたと返事
|----->| 09
|----->| 10
|　　　　 | Bが反応なし(08がタイムアウト)
|----->| 08 08から再送
|----->| 09
|----->| 10
|<-----| 10 10まで届いたと返事

(おわり)

965 ：デフォルトの名無しさん：2009/07/03(金) 17:48:54

>>963の
>もしも番号が連続しないことを検出したら連続する時点の
>ACKを返し、Bの再送まで待つ。
これ不要でした。
あと、ウィンドウサイズは双方でデフォルト値を決めておいて、
ACK返送時に一緒に送って変更するとかかな。

966 ：デフォルトの名無しさん：2009/07/03(金) 18:25:41

そこまでやるんなら、TCPでやればいいやん。

967 ：デフォルトの名無しさん：2009/07/03(金) 18:44:11

TCPは制御できないからね

968 ：デフォルトの名無しさん：2009/07/04(土) 00:27:45

TCP で制御できなくて UDP だと制御できるものって何?

大抵自前でやろうとすると結局 TCP に帰着するか、TCP
が注意深く避けている問題に気付かないかのどっちかだ。

TCP はポッと出てきた訳じゃなくて、何年もの実験と研
究を元にしていることを忘れちゃ駄目だ。もちろんそれ
を越えるものを考えられるなら話は別だけど。

969 ：デフォルトの名無しさん：2009/07/04(土) 00:34:40

>>967
お前よりは良く制御するわ。

970 ：デフォルトの名無しさん：2009/07/04(土) 01:12:16

TCPは低速リンクでも高速リンクでもそれなりに動作するように作られている。
状況を限定すれば余計な処理が省略できる。

971 ：デフォルトの名無しさん：2009/07/04(土) 01:28:57

TCPは返事が返ってこないとフリーズするじゃん。

972 ：デフォルトの名無しさん：2009/07/04(土) 01:37:49

しない。

973 ：デフォルトの名無しさん：2009/07/04(土) 01:55:22

>>970
当然↓位の考察は出来てるんだよな?

http://www.imasy.or.jp/~yotti/rfc2001j.txt

Stevens が亡くなってもうすぐ十年か…。

974 ：デフォルトの名無しさん：2009/07/04(土) 02:01:26

>>971
いいからRFC読めよアホ

975 ：デフォルトの名無しさん：2009/07/04(土) 02:39:48

ACKが帰ってくるまでの間に何か処理したい場合どうすんの？
スレッドとかなしで。

976 ：デフォルトの名無しさん：2009/07/04(土) 02:58:12

それTCPじゃなくてAPIの使い方の問題じゃん
アホはしねよ

977 ：デフォルトの名無しさん：2009/07/04(土) 17:42:42

DOSとかなら諦めろとしかいえないしなあ。

逆に何か処理してる間に、ACK返って来たら取りこぼすだろｗｗｗ
ACK帰ってくるのは待つしか無い。

978 ：デフォルトの名無しさん：2009/07/04(土) 17:51:26

だからTCP使わずに自分で制御するしかないんだよ

979 ：デフォルトの名無しさん：2009/07/04(土) 20:00:55

ども。上手くいきました。
>>977
ACK蓄えるぐらいのバッファはあるので問題なしでした。

980 ：デフォルトの名無しさん：2009/07/05(日) 08:48:54

>>977
>>978
いいからお前らアホはRFC読んでから出直してこいって。
馬鹿丸出しだぞ?

981 ：デフォルトの名無しさん：2009/07/05(日) 10:12:14

どのRFCかぐらい教えてやれば？

982 ：デフォルトの名無しさん：2009/07/05(日) 10:47:35

[RFC793] Postel, J., Editor, "Transmission Control Protocol,"
STD 7, RFC 793, September 1981.

28年前の基礎技術すらろくに理解できてないのに
それについて語ろうとする奴って何なんだ？

983 ：デフォルトの名無しさん：2009/07/05(日) 11:18:44

>>968
＞TCP で制御できなくて UDP だと制御できるものって何?

ネットワークの混雑を無視して、競合するTCPセッションのリソースを強引に奪うプログラムとか。ロスさせることを前提として20%ぐらいのFECかけて送信するみたいなの。

984 ：デフォルトの名無しさん：2009/07/05(日) 11:22:02

でもほとんどの中継機器はTCPに最適化されちゃってるんだよねぇ

985 ：デフォルトの名無しさん：2009/07/05(日) 11:34:29

>>982
> 28年前の基礎技術すらろくに理解できてないのに
> それについて語ろうとする奴って何なんだ？

「データシート(規格書でも、ソースでも、…、可)読めや、ゴルァ！！！」
「難しくて分かりません、取りあえず動かす方法教えてください」

ってのが、最近の流行りらしいからなぁ………

986 ：デフォルトの名無しさん：2009/07/05(日) 11:41:26

>>985
昔と今では決まり事の数が違いすぎるだろ・・・
人間が変わったわけじゃない、環境が変わったんだ。

987 ：デフォルトの名無しさん：2009/07/05(日) 12:13:42

>>986
それもそうなんだが、それ以前に
読もうとする意志のかけらも見当たらない奴が増えてる
現実もあったりするわけだが…

988 ：デフォルトの名無しさん：2009/07/05(日) 12:31:49

>>987
まぁ、プログラミング自体に夢が見られない時代だからな・・

989 ：デフォルトの名無しさん：2009/07/05(日) 12:36:42

腕があれば一本釣りされるいい時代。

990 ：デフォルトの名無しさん：2009/07/05(日) 14:24:22

腕が無くてもコスト重視で素人が割り当てられてる時代。

勉強する時間がないので正解だけ教えてください的なのは多いね。
応用効かなくてウマく動かなくて困りそうだが。

991 ：デフォルトの名無しさん：2009/07/05(日) 14:27:02

コスト重視にならないような？

992 ：デフォルトの名無しさん：2009/07/05(日) 14:52:04

君達はプログラマ在職中

決して顧客から感謝されたり

歓迎されることなくプログラマを終わるかもしれない

きっと非難とか叱咤ばかりの一生かもしれない

御苦労だと思う

しかし

プログラマが顧客から歓迎されちやほやされる事態とは

外資から攻撃されて企業存亡の時とかデスマーチ派遣の時とか

顧客が困窮し混乱に直面している時だけなのだ

言葉を換えれば

君達が日陰者である時のほうが

顧客は幸せなのだ

どうか、耐えてもらいたい

993 ：デフォルトの名無しさん：2009/07/05(日) 14:57:47

自衛隊は良いよな。
衣食住無料、しかも給料は高額。
それに比べてプログラマは・・・
鬱で自殺するプログラマより訓練で死ぬ自衛隊の方が遙かに少ない。

994 ：デフォルトの名無しさん：2009/07/05(日) 15:09:47

>>993
そう思うなら自衛隊入れば？

995 ：デフォルトの名無しさん：2009/07/05(日) 15:37:15

自衛隊の死者の方が桁違いに多いのを知らないのだろうか・・・

996 ：デフォルトの名無しさん：2009/07/05(日) 15:46:11

>>995
それは全員志願ですよ。

997 ：デフォルトの名無しさん：2009/07/05(日) 15:48:03

>>993
だったらさっさと自衛隊に入れよクズ

>>996
自殺者なんてみんな志願だろw
自殺は甘え。

998 ：デフォルトの名無しさん：2009/07/05(日) 15:49:19

↓次ｽﾚよろ