5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

ネットワークプログラミング相談室 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
過去スレ:
Port21 ttp://pc11.2ch.net/test/read.cgi/tech/1204287577/
Port20 ttp://pc11.2ch.net/test/read.cgi/tech/1186418855/
Port19 ttp://pc10.2ch.net/test/read.cgi/tech/1159692799/
Port18 ttp://pc11.2ch.net/test/read.cgi/tech/1171029896/
Port17 ttp://pc8.2ch.net/test/read.cgi/tech/1148944560/
Port16 ttp://pc8.2ch.net/test/read.cgi/tech/1136005644/
Port15 ttp://pc8.2ch.net/test/read.cgi/tech/1128088448/
Port14 ttp://pc8.2ch.net/test/read.cgi/tech/1118469143/
Port13 ttp://pc8.2ch.net/test/read.cgi/tech/1109793931/
Port12 ttp://pc5.2ch.net/test/read.cgi/tech/1102427855/
Port11 ttp://pc5.2ch.net/test/read.cgi/tech/1096187183/
Port10 ttp://pc5.2ch.net/test/read.cgi/tech/1090385857/
Port9 ttp://pc5.2ch.net/test/read.cgi/tech/1080658835/
Port8 ttp://pc5.2ch.net/test/read.cgi/tech/1073560271/
Port7 ttp://pc5.2ch.net/test/read.cgi/tech/1063035045/ ★行方不明
Port6 ttp://pc5.2ch.net/tech/kako/1052/10521/1052106444.html
Port5 ttp://pc2.2ch.net/tech/kako/1040/10402/1040220302.html
Port4 ttp://pc3.2ch.net/tech/kako/1034/10342/1034236536.html
Port3 ttp://pc3.2ch.net/tech/kako/1023/10233/1023359282.html
Port2 ttp://pc.2ch.net/tech/kako/1006/10062/1006258198.html
Port1 ttp://pc.2ch.net/tech/kako/970/970344582.html

3 :デフォルトの名無しさん: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
gj

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するのはコストがかかるんだよwww

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

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

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
自分で自分の日本語の不自由さを責めなくていいんだよw

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

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

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
もはやそんな話から始めなければならなくなったかwww

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

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

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でもスレッドプールあるけど、
いくつか種類がある。

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

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

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
サーバー1台じゃないだろ 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
いきなりレス数増えてると思ったら新年からファビョってんのかw

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ポートはモデムの設定等で開いていない限りは、早ければ1分程度で
受信不能になってしまいます。

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で受け取るような
ライブラリを開発しています。
映像は、圧縮、非圧縮の2タイプ有るので、
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
1スレッド1コネクションでも問題は無いけどね。ネットワークプログラミングの難しさはエラー処理にある。

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

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

解答。

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

変数aの値は  10
変数bの値は  20



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で音声データを送信〜受信的なところまでは分かるのですが、
受信したものをどうやって再生するんだよ!という状態です。

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

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

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

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

145 :デフォルトの名無しさん:2009/01/15(木) 22:47:31
>>144
ありがとうございます!
母国語以外を無意識に避けていて気付きませんでした!
私のような愚か者がいるから日本の国力が低下するのですね!
これからは他のことでも進んで他国語からも情報を得る努力をします!
1人でも国力底上げしてやるぜ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
1秒毎に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
d

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
1パケットって何バイトだった?


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

現実的には案1で十分だと思う。クライアントソフトのクラックは別途対策する
(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、この2つで十分というのはおもしろいと思う

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

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


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
俺もド素人w

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
C言語です。

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
ファイアーウォールは外向きのパケットが通るとその発信元ポート、アドレス、
及び通信先ポート、アドレスの4組の情報を「セッション」として覚える。
パケットが帰って来るとそのセッションに当てはめ、一致するセッションがあれば
通してあげる。

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は0よ!

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>の4つ組は決定するわけで、
そのあとで、「やっぱりポート変えたいんだけど」とか
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さんが書いてるように4組で識別しているからだと理解しています。

>>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
わからないのは、君のせいではなく、その文章を書いた人間がバカだからです。

「日本語でおk」と言ってやりなさい。

456 :デフォルトの名無しさん:2009/02/18(水) 23:23:10
>>455
ΣΣΣ
単位がもらえなくな・・・ry

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
VM

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
は?

130 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)