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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

このサイトでは、
main関数でwinsock2の初期化後ソケットの作成を試みて、
返り値がINVALID_SOCKETの場合returnで終了していますが、
その場合WSACleanupを処理しないことになりますがこれでいいのでしょうか？

// ソケットの作成
sock0= socket(AF_INET,SOCK_STREAM,0);
if (sock0 == INVALID_SOCKET){
　printf("socket : %d\n", WSAGetLastError());
　getch();
　return -1;
　}

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

解答。

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

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

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

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

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

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

　　　　

？

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

？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

176:175
09/01/22 11:14:40
思い出した。↑の方法でも中間者攻撃対策にはならないんだった。

177:デフォルトの名無しさん
09/01/22 11:25:02
正規のクライアントがクラックされてクローンを作られるのは防ぎようがないかな。

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

178:デフォルトの名無しさん
09/01/22 19:16:30
>>168
ここで答え出てるだろ。
クライアントでランダムな非対称鍵作って
暗号化用の鍵を相手に渡す。

179:デフォルトの名無しさん
09/01/22 21:43:51
MMOみたいな延滞厳禁な物に対して
暗号化を施すのも正直どうかと思うけどな

180:デフォルトの名無しさん
09/01/22 22:00:40
暗号化コストなんて送受信に比べたらカスみたいなもんだろ

181:デフォルトの名無しさん
09/01/22 23:33:12
共通鍵にしろ公開鍵にしろ
強度を高めようとしたら結構負荷がかかるぞ

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

182:デフォルトの名無しさん
09/01/23 10:01:21
暗号化コストは結構でかいよ。
LANでギガビットイーサ+SSHだとネットの性能に暗号処理がおいつかない。

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

183:デフォルトの名無しさん
09/01/23 11:36:09
お前は一体何の話をしてるんだ

184:デフォルトの名無しさん
09/01/23 17:20:28
MMOでクライアントからサーバーに巨大なデータは送らない。

185:デフォルトの名無しさん
09/01/24 17:20:09
UDPの受信で到着順番が入れ替わる対応をするため
受信データにシーケンシャルなインデックスを入れて
受信時にソートするとする。

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

186:デフォルトの名無しさん
09/01/24 18:34:50
必要なら取り込む、不要なら捨てる

187:デフォルトの名無しさん
09/01/25 10:42:57
185が自分で言っているように仕様によるとしか言えない。

188:デフォルトの名無しさん
09/01/25 13:31:10
やっぱそうだよなー
でもせっかく届いたデータを捨てるのも勿体無い気がする・・・

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

189:デフォルトの名無しさん
09/01/25 13:38:41
そこを頑張り過ぎるといつのまにか劣化TCPを作るハメになるぞ

190:デフォルトの名無しさん
09/01/25 13:50:27
分散コンピューティング環境では思い切りが必要。

191:デフォルトの名無しさん
09/01/25 14:46:45
迷ったら、TCPを使わない理由を考えなしたほうがいい

192:デフォルトの名無しさん
09/01/25 22:02:47
意味判らんが
UDPの方がプログラマ寄りの考え方だぞ

193:デフォルトの名無しさん
09/01/25 22:24:03
それこそ意味がわからん。

194:デフォルトの名無しさん
09/01/25 22:27:12
プログラマ寄り？

195:デフォルトの名無しさん
09/01/25 22:51:09
まあ生パケットに近い (=プログラマの裁量範囲が大きい) と
言いたかったのではないかとエスパーしてみる。

196:デフォルトの名無しさん
09/01/25 23:08:06
じゃあアセンブラで書けよ。

197:デフォルトの名無しさん
09/01/25 23:30:12
また意味わからん奴が出てきたぞ

198:デフォルトの名無しさん
09/01/26 08:55:02
TCPとUDP、この２つで十分というのはおもしろいと思う

199:デフォルトの名無しさん
09/01/26 11:31:29
十分じゃないからその上の層にも下の層にもプロトコルがあるんだろうが。
tracerouteコマンドのように下の層を直接使うアプリもあるし。

200:デフォルトの名無しさん
09/01/26 20:28:26
ネットワークプログラミングに興味を持って始めてみようと思うのですが、
Windowsではwinsockが主流なのでしょうか？
長らく更新されていないようですけど、それだけ完成度が高いということですか？

201:デフォルトの名無しさん
09/01/26 21:30:45
うん

202:デフォルトの名無しさん
09/01/26 21:38:43
HTTPリクエストだけならWininetAPIの方が楽ちん

203:デフォルトの名無しさん
09/01/26 22:09:07
Winsock以外のプロトコルスタックの実装もあるにはあるけど、実際に使われてるのを
最近は見たことない。Winsockで十分だからね。

204:デフォルトの名無しさん
09/01/26 22:30:39
なんか意外な気もしますが普通に現役なんですね
取っ掛かりは簡単そうだし、少しやってみようと思います

205:デフォルトの名無しさん
09/01/26 22:34:01
ptrace(2)を使うのはほとんどのUNIXでお勧めではない。
詳しくはmanpageを読んでくれ。

206:デフォルトの名無しさん
09/01/27 03:58:49
ふつ～straceだよね

207:デフォルトの名無しさん
09/01/27 09:08:04
tracerouteは
UDPを投げてICMPの戻りを使うタイプのものと
ICMPを投げてICMPの戻りを使うものがある
この理解であってる？

208:デフォルトの名無しさん
09/01/27 14:05:03
あってる。

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

209:デフォルトの名無しさん
09/01/29 23:21:46
ちょっと引くぐらいくだらない質問だと思いますが、教えてください。

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

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

210:デフォルトの名無しさん
09/01/29 23:45:01
そこいうポートって？

211:デフォルトの名無しさん
09/01/29 23:47:25
「で」が抜けた

212:デフォルトの名無しさん
09/01/29 23:49:15
あ、すいません。
書き方が悪かったです。

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

213:デフォルトの名無しさん
09/01/30 00:01:21
>>209
恐らくネットワークの下層の存在を知らないんじゃないかな？　
TCP, UDP, IPまでは物理的な通信ハードウェアとは隔離されたレベルの
通信規格。　

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

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

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

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

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

215:デフォルトの名無しさん
09/01/30 00:12:12
>>213
そういうことですか・・・少し理解が進みました。
ありがとうございます。

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

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

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

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

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

216:デフォルトの名無しさん
09/01/30 00:16:08
>>214
そのファームの移植・・・という作業なのです。
（CPUが異なるボードへの移植です）

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

ちょっと憂鬱です。

217:デフォルトの名無しさん
09/01/30 00:20:12
>>3の本は読まないとね。

218:デフォルトの名無しさん
09/01/30 00:36:20
>>215-216
WireShark とかインストールして、ネットワーク上のパケット
見れば理解が少しはすすもかも。

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

219:デフォルトの名無しさん
09/01/30 00:37:35
移植するのに上位層から眺めてたら、わけわかめになるんじゃないの？

220:デフォルトの名無しさん
09/01/30 01:12:00
>>214
一応ルーターベンダでルータのコードいじってた。 IP, ルーティングが主専門だったが
時々データリンクもいじったし、ブートROMを新しいハードに移植もしたことある。

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

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

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

221:デフォルトの名無しさん
09/01/30 01:15:50
「データリンク層がLAN」とか良く言えるなw

222:デフォルトの名無しさん
09/01/30 01:19:58
>>220

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

224:デフォルトの名無しさん
09/01/30 03:10:24
>>223
そういうやり方もありかと
あと、TCPで使うタイマーをどうするかぐらい？
ハードに依存した部分がソースで分離されてれば楽だろうね。
209は自分のMACアドレスとかどうするつもり何だろう？

225:デフォルトの名無しさん
09/01/30 22:07:47
>>218
今日はEtherealを使ってパケットのやり取りをみてみました（ARPだけですが）
確かに理解は進んで、イメージがつかめてきました。

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

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

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

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

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

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

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

226:デフォルトの名無しさん
09/01/30 23:24:38
なぜいまさらEtherealなの？最新のWiresharkにしときなさい。

227:デフォルトの名無しさん
09/01/31 02:00:22
>まだ来週からは、パケットの送受信をハードがどう行っているかの解析や
>TCP/IPやらUDPやらその他もろもろの解析が続くので

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

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

URLﾘﾝｸ(uproda11.2ch-library.com)

お願いします。

229:デフォルトの名無しさん
09/01/31 12:54:42
コードを流し見しただけだが
ソケット関係は入出力を含めてエラー処理が甘すぎ

230:デフォルトの名無しさん
09/01/31 13:13:07
何も見てないがWinSockのせいじゃないぞ

231:デフォルトの名無しさん
09/02/01 13:00:01
>>230
何のせいですか？

232:デフォルトの名無しさん
09/02/01 13:12:27
>>229-230
例外を処理していないのが原因だったようです。
ありがとうございました。

233:デフォルトの名無しさん
09/02/01 13:19:05
server側のFD_CLOSEにトラップしかけてトレースしたらすぐ分かるでしょ

234:デフォルトの名無しさん
09/02/01 16:26:44
>>228
Backdoor....ヒィーーーーッ、ガクガクブルブル

235:デフォルトの名無しさん
09/02/01 17:23:23
やべっ
落として実行しちゃったけどBackdoor仕掛けられちゃったか・・・

（

236:デフォルトの名無しさん
09/02/01 21:40:15
ご愁傷様です

237:デフォルトの名無しさん
09/02/01 21:51:01
落としてる途中で
怪しいと思ったので
放置してたんだけど
やっぱそうなん？

238:デフォルトの名無しさん
09/02/01 21:52:39
あっぶね
落したけど実効はしてない

239:デフォルトの名無しさん
09/02/01 22:20:37
UDPのソケットを作成してbind後に
どこかのアドレスにsendtoすると
selectでreadfdsが反応しちゃうんだけど
そゆもの？
なんで自分が受信可能になるの？

240:デフォルトの名無しさん
09/02/01 22:21:47
ちゃんとselect用のsocket分けてますか

241:デフォルトの名無しさん
09/02/01 22:48:30
ソケットは1つしか作成していません。
そのソケットをbindしてselectにセットしています。
さらにそのソケットでsendtoしてるんだけど、
それがまずいってことですか？

242:239
09/02/01 23:25:56
すいません、送信アドレスが127.0.0.でしたorz
申し訳ないです、忘れて下さい(´・ω・`)

243:デフォルトの名無しさん
09/02/01 23:58:27
｡゜（ﾟ´Д｀ﾟ）ﾉｳﾝｺ-

244:デフォルトの名無しさん
09/02/02 00:11:28
タヒぬ

245:デフォルトの名無しさん
09/02/02 02:12:56
>>228を落としてウィルススキャンして見たんだが反応しない
バックドアってどうしたら発見できるの？

246:デフォルトの名無しさん
09/02/02 03:04:46
作っているアプリの名前がbackdoor？

247:デフォルトの名無しさん
09/02/02 06:21:16
デスクトップイメージを送信している
それだけでbackdoorと言っても差し支えない

248:デフォルトの名無しさん
09/02/03 01:11:56
>すいません、送信アドレスが127.0.0.でしたorz
ﾜﾗﾀ

249:デフォルトの名無しさん
09/02/03 23:29:30
LinuxでIPアドレスが分かっているLAN内の他のホストのMACアドレスを知るプログラムを作りたいのですがどうすればいいですか？

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

250:デフォルトの名無しさん
09/02/03 23:34:48
なんでping→arp -aがだめなの？

251:デフォルトの名無しさん
09/02/03 23:53:07
ARPパケットの送信と受信がしたいのでは？

252:デフォルトの名無しさん
09/02/04 00:34:10
arp -a
一行

253:デフォルトの名無しさん
09/02/04 00:50:26
URLﾘﾝｸ(publib.boulder.ibm.com)
URLﾘﾝｸ(publib.boulder.ibm.com)

254:デフォルトの名無しさん
09/02/04 12:40:11
>>249
arpのソースをリンクすればいいんじゃないか？

255:デフォルトの名無しさん
09/02/04 13:27:29
>>254
ライセンス関連であまり悩みたくないので他のプログラムのソースを取り込むのは避けたいです。

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

256:デフォルトの名無しさん
09/02/04 13:29:23
>>253
ありがとうございます。参考にします。

257:デフォルトの名無しさん
09/02/04 13:30:26
>>250
他のプロセスを起動したくないからです。

258:デフォルトの名無しさん
09/02/04 13:40:19
注文が多いのう

259:デフォルトの名無しさん
09/02/04 16:18:33
>>255
つ　URLﾘﾝｸ(www.netlib.org)

260:デフォルトの名無しさん
09/02/04 16:20:51
>>259
あ、逆だった。　こっちだ orz
URLﾘﾝｸ(www.packetfactory.net)　

261:デフォルトの名無しさん
09/02/04 21:38:43
>>257
Linux前提なら /proc/net/arp 読めばいいんじゃね?
arpコマンドだってこれ読んでるだけだよ。

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

262:デフォルトの名無しさん
09/02/04 21:49:06
キャッシュについては
ていうかpingも自分で実装？

263:デフォルトの名無しさん
09/02/04 23:54:13
>>260
ありがとうございます。
やっぱり標準装備のライブラリじゃできないですかね。。
導入するならこれかlibpcapかな。

264:デフォルトの名無しさん
09/02/04 23:55:38
>>262
いや、接続しようとするだけで問題なし。
出来なくてもARPは行われるから。

265:デフォルトの名無しさん
09/02/04 23:56:02
>>261
ありがとうございます。
確かにそれはいいアイディアですね。
テキスト処理が若干面倒ですが。

266:デフォルトの名無しさん
09/02/04 23:57:50
>>262
御存じのこととは思いますが、pingとarpキャッシュは直接関係ありませんよ。
pingがアドレス解決するのでその副作用でarpキャッシュが更新されるだけです。

267:デフォルトの名無しさん
09/02/05 17:34:42
>>264
確かにそれはいいアイディアですね。
自分でARP投げるのも出来ませんかね。

268:デフォルトの名無しさん
09/02/05 18:11:46
URLﾘﾝｸ(www.itbook.info)

269:デフォルトの名無しさん
09/02/05 21:37:23
URLﾘﾝｸ(arco.esi.uclm.es)

270:デフォルトの名無しさん
09/02/05 22:45:25
URLﾘﾝｸ(www.secdev.org)
URLﾘﾝｸ(www.secdev.org)

271:デフォルトの名無しさん
09/02/05 22:45:39
>>267
こっちが聴きたい。「あなたは実装できないのですか？」

272:デフォルトの名無しさん
09/02/05 22:47:14
URLﾘﾝｸ(www.designandcommunication.co.jp)

273:デフォルトの名無しさん
09/02/05 22:49:29
>>271
Cでは出来るけど >>249 の言うような

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

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

274:デフォルトの名無しさん
09/02/05 22:55:44
URLﾘﾝｸ(ilab.cs.byu.edu)
URLﾘﾝｸ(heather.cs.ucdavis.edu)
URLﾘﾝｸ(www.amazon.co.jp)
URLﾘﾝｸ(d.hatena.ne.jp)
URLﾘﾝｸ(www.onlamp.com)
URLﾘﾝｸ(simonwillison.net)

275:デフォルトの名無しさん
09/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:デフォルトの名無しさん
09/02/05 23:31:13
なんとか出来そうです
ありがとうございました

277:249 ◆ZHAPRHY6Ag
09/02/06 00:13:24
話の流れが分からなくなりつつあるので名前を付けます。

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

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

次ページ