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

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

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

278:249 ◆ZHAPRHY6Ag
09/02/06 00:27:48
大切なことを言い忘れていましたが、CかC++で実装したいと考えています。

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

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

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

279:デフォルトの名無しさん
09/02/06 00:35:16
もうとっくに書き終わったかと思ったよw

280:デフォルトの名無しさん
09/02/06 00:38:57
>>249
IPアドレスが分かっているLAN内の他のホストのMACアドレスを知る
>>278
MACアドレスが分かっているリモートホストのIPアドレスが知りたい

謎ですなあ。

281:デフォルトの名無しさん
09/02/06 01:41:03
int get_mac_address(struct arpreq *req)
じゃなくて
int get_ip_address(struct mac_addr *mac)
だよなぁ
謎

282:249 ◆ZHAPRHY6Ag
09/02/06 01:57:16
ああそうですね。間違えました。求めるたいのはIPアドレスです。

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

283:249 ◆ZHAPRHY6Ag
09/02/06 02:00:25
>>280 >>281
ああちがいました。
求めたいのはMACアドレスです。

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

284:249 ◆ZHAPRHY6Ag
09/02/06 02:02:28
（>>278は間違いなので書きなおします。）

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

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

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

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

285:デフォルトの名無しさん
09/02/06 02:03:01
>>278
> 標準関数でint get_mac_address(struct arpreq *req) のような関数があると理想的です

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

286:249 ◆ZHAPRHY6Ag
09/02/06 02:12:48
無いのですね。わかりました。ありがとうございました。

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

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

287:デフォルトの名無しさん
09/02/06 03:21:05
ｽﾚﾘﾝｸ(tech板)
ここでマルチしてんのか

288:デフォルトの名無しさん
09/02/06 08:20:08
何がマルチ？

289:デフォルトの名無しさん
09/02/06 08:44:00
>>282-283
指摘されているにも関わらず同じ間違いを繰り返してしまうキミは
プログラミングを止めた方がいい。経験上。

290:デフォルトの名無しさん
09/02/06 09:15:51
同じじゃないですよ？

291:デフォルトの名無しさん
09/02/06 09:17:48
愚者は経験に従うとも言います。

292:デフォルトの名無しさん
09/02/06 10:29:01
神だって何度も間違える。

293:デフォルトの名無しさん
09/02/06 10:32:30
プログラマは2度間違えない。

294:デフォルトの名無しさん
09/02/06 11:11:28
人間は何度でも間違える。

295:デフォルトの名無しさん
09/02/06 11:33:57
プログラマは2度間違えない。

296:デフォルトの名無しさん
09/02/06 13:21:01
プログラマーって最高ですね。

297:デフォルトの名無しさん
09/02/06 15:16:43
おばあちゃんが執事にするならプログラマが一番だって。

298:デフォルトの名無しさん
09/02/06 15:22:32
>>284
ここにいる奴に書かせるつもりだなw

299:デフォルトの名無しさん
09/02/06 16:19:25
ブロードキャストのパケット監視するとか？

300:デフォルトの名無しさん
09/02/06 16:30:03
そうそう/proc/net/arpをずーと監視してればいつかは…
っておい！

301:デフォルトの名無しさん
09/02/06 21:08:50
過疎

302:デフォルトの名無しさん
09/02/06 21:18:49
↑過疎の原因

303:デフォルトの名無しさん
09/02/06 22:22:51
蘇我入鹿

304:デフォルトの名無しさん
09/02/07 01:18:21
金玉かゆい

305:デフォルトの名無しさん
09/02/07 01:34:59
なるほど
ありがとうございました

306:デフォルトの名無しさん
09/02/07 03:05:56
ProxyARP

307:デフォルトの名無しさん
09/02/07 03:13:40
URLﾘﾝｸ(www.geocities.jp)

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

309:デフォルトの名無しさん
09/02/07 12:41:32
ドライバが対応していればその機能を使う。
対応していないなら、そういうドライバを作る。

310:デフォルトの名無しさん
09/02/07 14:18:21
複雑だと思うならつかわなきゃいいんじゃねーの？
なんでアホはあるもの全部使わなきゃ気がすまねーの？

311:デフォルトの名無しさん
09/02/07 14:23:11
どっちにしろ対象を絞り込むときに選別しなきゃならんわけで

312:デフォルトの名無しさん
09/02/07 14:44:47

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

313:デフォルトの名無しさん
09/02/07 15:22:25
同じフィルタリングでも、カーネルモードとユーザランドでは性能が段違い。

314:デフォルトの名無しさん
09/02/07 15:22:28
素人さん向け
URLﾘﾝｸ(www.tef-room.net)
URLﾘﾝｸ(www.space-peace.com)

315:デフォルトの名無しさん
09/02/07 19:10:19
俺もド素人ｗ

316:デフォルトの名無しさん
09/02/07 19:11:12
TCPソケットでconnectすると
接続元アドレスが自動で設定されると思うんだけど
複数IPアドレスがあった場合どうなるの？

317:デフォルトの名無しさん
09/02/07 19:33:02
bind

318:デフォルトの名無しさん
09/02/07 19:57:20
なるほど
ありがとうございました

319:デフォルトの名無しさん
09/02/07 20:10:45
処理するのにbindすればいいのは分かるんだけど
bindしないでconnectした時のアドレス割り当てが
どういったルールになってるのかなって。

320:デフォルトの名無しさん
09/02/07 20:35:40
普通はそのインターフェースのプライマリアドレス

321:デフォルトの名無しさん
09/02/07 21:24:44
>>320
ちゃんとプライマリとか見てくれるのか
ありがとー

322:デフォルトの名無しさん
09/02/08 06:32:35
何でこの板IDないの？

323:デフォルトの名無しさん
09/02/08 07:49:43
紳士だからさ

324:デフォルトの名無しさん
09/02/08 09:44:13
変態という名の紳士

325:デフォルトの名無しさん
09/02/08 22:47:12
地震キタ

326:デフォルトの名無しさん
09/02/09 01:07:46
thread_Aにてepoll_wait中に、thread_Bからepoll_ctlで監視対象fdを操作(EPOLL_CTL_DELとか)しても、
即座にthread_Aで止まってるepoll_waitは反映してくれない？

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

327:デフォルトの名無しさん
09/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:デフォルトの名無しさん
09/02/10 11:25:55
んー
同じセグメントのIPが複数振られてたらどっちが使われる？

329:デフォルトの名無しさん
09/02/10 11:26:06
プログラム言語はなぜ「言語」と呼ばれるのでしょう？
通常使っている言語とどのような共通点があるか？
またどのような相違点があるか？

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

330:デフォルトの名無しさん
09/02/10 11:40:40
>>329
ウィキペれ。

331:デフォルトの名無しさん
09/02/10 11:43:37
ウィキにのってないポ（;・∀・）

332:デフォルトの名無しさん
09/02/10 11:45:36
>>328
>>327に書いてあるでしょ。

333:デフォルトの名無しさん
09/02/10 13:56:50
>>332
同じインタフェースに 192.168.0.1/24 と 192.168.0.2/24 が振られているときに
192.168.0.254 に接続したらどうなるか、って話でしょ。>>327には書いてないと思うが。

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

334:デフォルトの名無しさん
09/02/10 22:47:46
質問です。

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

335:デフォルトの名無しさん
09/02/10 22:53:52
あり得ません。

336:デフォルトの名無しさん
09/02/10 23:00:45
>>335
ありがとうございました

337:デフォルトの名無しさん
09/02/10 23:01:28
おい、誰の発言かわからん一言を、そんなに簡単に信じちゃうのかよ。

338:デフォルトの名無しさん
09/02/10 23:18:03
>>337

339:デフォルトの名無しさん
09/02/10 23:27:58
本当はどうなんでしょうか？

340:デフォルトの名無しさん
09/02/10 23:32:09
わかりません

341:デフォルトの名無しさん
09/02/10 23:36:14
>>339 RFC 読めばええんちゃう？

342:デフォルトの名無しさん
09/02/11 00:01:12
普通にありえる。

343:デフォルトの名無しさん
09/02/11 00:08:08
OSのバグみたいな、よっぽどのことがない限りないでそ。

344:デフォルトの名無しさん
09/02/11 00:08:56
OSと何の関係が

345:デフォルトの名無しさん
09/02/11 00:12:19
UDPソケットって何?

346:デフォルトの名無しさん
09/02/11 00:17:01
そう来ますか

347:デフォルトの名無しさん
09/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:デフォルトの名無しさん
09/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:デフォルトの名無しさん
09/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:デフォルトの名無しさん
09/02/11 00:27:19
最初から書いとけ馬鹿

351:デフォルトの名無しさん
09/02/11 01:29:43
みなさん、ありがとうございました

352:デフォルトの名無しさん
09/02/11 03:41:46
何に対して礼を言っているのだ

353:デフォルトの名無しさん
09/02/11 03:42:37
始めてみようかと思うんですが。
まずなにからすればいいんでしょうか？
ダイアログにWebBrowserコントロールを張り付ければいいんですか？

次ページ