ネットワークプログラ ..
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コントロールを張り付ければいいんですか？
354:デフォルトの名無しさん
09/02/11 03:43:12
>>352
みなさん ではないんでしょうか？
355:デフォルトの名無しさん
09/02/11 10:16:31
>>353
スレ違い。
356:デフォルトの名無しさん
09/02/11 10:38:13
>>347-349
力抜けよ
357:デフォルトの名無しさん
09/02/11 11:20:27
アッー！
358:デフォルトの名無しさん
09/02/11 17:23:26
なんだこの流れは…たまげたなぁ
359:デフォルトの名無しさん
09/02/11 21:00:32
>>353 はもっと評価されていい。
>始めてみようかと思うんですが。
何をだ！？と思った次の瞬間、
>まずなにからすればいいんでしょうか？
いや知らんがなー！と突っ込まずにはいられない。
360:デフォルトの名無しさん
09/02/12 01:38:36
神との対話を見た
361:デフォルトの名無しさん
09/02/12 09:32:53
どこに書けばいいのかわからないので、お手数ですが。
Rubyで書いた、ウェブページとそこのリンク先を取り込むスクリプトを
動かしていたら途中でconnect refusedになって以後つながりません。
"www.linux.org"だったんですけど、他では問題ありません。
図書館でやっても途中で切れました。
某図書館では"www.linux.org"につながらなくなっているかもしれませんゴメンナサイ。
いったいどうゆうことなんでしょうか。
なにが気に入らなかったんでしょうか。
まる二日たちますが、接続拒否は解除されるんでしょうか。
362:デフォルトの名無しさん
09/02/12 10:45:59
>>361
一度に多接続すると制限されることはあるね。
どれくらいの期間制限されるかはサイトのポリシーだから一概には言えないね。
363:デフォルトの名無しさん
09/02/12 13:50:33
接続拒否されるってどんなスクリプト流したんだよ・・・
364:デフォルトの名無しさん
09/02/12 14:25:13
既存サイトを攻撃してはいけません
365:デフォルトの名無しさん
09/02/12 15:22:03
一度でも攻撃受けたとこはこの辺厳しい
366:デフォルトの名無しさん
09/02/12 15:26:12
なんて迷惑な奴
367:デフォルトの名無しさん
09/02/12 19:14:35
お約束ですが
通報しました
368:デフォルトの名無しさん
09/02/12 20:17:07
URLﾘﾝｸ(www.itmedia.co.jp)
369:デフォルトの名無しさん
09/02/12 20:20:41
IPアドレスを取得まではできたのですが、
取得したIPアドレスを利用して「ping」をうちたいのですが
どうしたらpingをうつプログラム書けますか？
手順を教えてください（ex 関数などを）
370:デフォルトの名無しさん
09/02/12 20:29:12
使ってる言語くらい書け。
371:デフォルトの名無しさん
09/02/12 20:50:31
Ｃ言語です。
372:デフォルトの名無しさん
09/02/12 22:04:37
ping()
373:デフォルトの名無しさん
09/02/12 22:20:59
なんで途中までは出来た、みたいな言い方になってんだ
374:デフォルトの名無しさん
09/02/12 22:57:05
>>369 ping したいんだけだたら system("ping ...")
375:デフォルトの名無しさん
09/02/12 23:26:29
おまいら、理解力の無い俺に救いの手を・・・
ルータ越しにサーバーとクライアントのプログラムを走らせるとして、
サーバーをSourcePort10000で立ち上げる。
クライアントをSourcePort5000、DestinationPort10000でサーバーに接続する。
この場合、サーバー側のポート10000を空けないと接続できないんだけど、
クライアント側はポートを空けなくても送受信できちゃいます。
なんでなの？(´・ω・`)
376:デフォルトの名無しさん
09/02/12 23:29:40
インバウンドしかブロックしないファイアーウォールなんだろ
377:デフォルトの名無しさん
09/02/12 23:33:44
>>375
> サーバーをSourcePort10000で立ち上げる。
SourcePort→AcceptPort
378:デフォルトの名無しさん
09/02/12 23:37:00
>>376
クライアントは受信もできちゃうんだけど
そゆものなの？(´・ω・`)
>>377
AcceptPortだったか
ありがとうございます。
379:デフォルトの名無しさん
09/02/12 23:57:36
>>378
そゆものでしょ
380:デフォルトの名無しさん
09/02/13 01:01:06
>>379
そんなのいやだぁぁぁ
ちゃんと理解したいぃぃぃ
なんでポート開いてないのに受信できるの！
( ﾟдﾟ)＜誰かぁぁぁぁ
381:デフォルトの名無しさん
09/02/13 01:18:21
>>380
ファイアーウォールは外向きのパケットが通るとその発信元ポート、アドレス、
及び通信先ポート、アドレスの４組の情報を「セッション」として覚える。
パケットが帰って来るとそのセッションに当てはめ、一致するセッションがあれば
通してあげる。
382:デフォルトの名無しさん
09/02/13 01:32:24
SPI
383:デフォルトの名無しさん
09/02/13 01:39:11
>>381
おー、そうなのですか
だからサーバーはポート開けないとダメなのかー
理解できますた。
分かりやすい解説ありがとうございましたヽ(´ー｀)ノ
>>382
SPIググってみました。
Stateful Packet Inspection
これか、これなのか！
勉強になりますたヽ(´ー｀)ノ
384:デフォルトの名無しさん
09/02/13 15:31:17
ヽ(´ー｀)ノヽ(´ー｀)ノヽ(´ー｀)ノヽ(´ー｀)ノヽ(´ー｀)ノ
385:デフォルトの名無しさん
09/02/13 20:54:37
無免許でのネットワークプログラミングは処罰の対象ですよ。
386:デフォルトの名無しさん
09/02/13 20:57:16
また大阪か
387:デフォルトの名無しさん
09/02/13 21:38:50
ネットワーク従事者の許認可は逓信省電波管理局の管轄です
388:デフォルトの名無しさん
09/02/14 10:16:09
免許は逓信大臣が交付じゃね？
389:デフォルトの名無しさん
09/02/14 10:28:44
情報処理技術者試験 (ネットワーク) は、橋本龍太郎 通産大臣 (当時) だったな。
390:デフォルトの名無しさん
09/02/14 23:35:59
高負荷になるとrecvがECONNRESETを返すようになってしまいます。
なにか心当たりがある方いらっしゃいますか？
391:デフォルトの名無しさん
09/02/14 23:38:14
>>390
リモートのホストに聞いてください。
392:デフォルトの名無しさん
09/02/14 23:41:18
「おらくたびれただよ、ちょっと休ませてくれかの？」
393:デフォルトの名無しさん
09/02/15 00:50:10
>>391
リモートのホストもこちらの制御下なのですが。。
394:デフォルトの名無しさん
09/02/15 00:50:39
じゃあ聞けよ。
395:デフォルトの名無しさん
09/02/15 00:50:59
どうやって制御してるの？
396:デフォルトの名無しさん
09/02/15 01:21:34
>>395
リモートのホストに聞いてください。
397:デフォルトの名無しさん
09/02/15 01:23:55
>>396
ちがう。
リモートのホストが>>393の制御下にあるというから、
どうやって制御しているのかを聞いている。
398:デフォルトの名無しさん
09/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:デフォルトの名無しさん
09/02/15 11:00:24
>>398
> （recvで0が返ってくるまでcloseしないとか）
& shutdown
400:デフォルトの名無しさん
09/02/15 11:00:38
>>398
最後サーバからなにsendしてるのかしらんけど
双方のパケットの内容はモニターしてチェックしたの？
してないんだったらまずはそっからじゃね？
401:デフォルトの名無しさん
09/02/15 11:00:44
>>398
URLﾘﾝｸ(www.kt.rim.or.jp)
402:デフォルトの名無しさん
09/02/15 11:45:12
>>399,401
ありがとうございます。
1. データ送信を完了する。
2. shutdown()をhowパラメータを 1 に設定して呼び出す。
3. recv()が 0 を返却するまでループする。
4. closesocket()を呼び出す。
1の「送信を完了する」というのは、実際に送信が完了したかの確認ではなく、
send(write)を呼んでstatusがOKかを確認するということでいいんですかね？
とりあえず、試してみます。
403:デフォルトの名無しさん
09/02/15 11:57:05
そだね、最後にちゃんとFINの立ったTCPセグメントを送ってやるって事。
recv側はちゃんとFINの立ったTCPセグメントを食ってやるって事。
それでどちら側もちゃんとshutdownできる。
何も難しいことはやってない。
404:デフォルトの名無しさん
09/02/16 19:23:21
非同期ソケットでFD_READの通知がきたとき
int ret = recv(socket , buf , 128 , 0 );//whileループは使わない。
ret == -1はあるきがするのですが(ブロッキングなど)
ret == 0はあるのでしょうか？
ブロッキングソケットの場合はrecvでとまっているので ret == 0で切断などであるとは思うのですが。
405:デフォルトの名無しさん
09/02/17 02:39:11
マニュアルにないと書いてなければあると思わなければいけない。
406:デフォルトの名無しさん
09/02/17 10:35:44
>>361ですが、やっとこ、つながりました。一週間でしたね。
サーバー管理している皆様
セキュリティは、ほどほどにお願いします。
407:デフォルトの名無しさん
09/02/17 10:38:02
お前氏んでいいよ
408:デフォルトの名無しさん
09/02/17 12:21:38
>>407
おまえの母ちゃんよりマシ。
409:デフォルトの名無しさん
09/02/17 12:39:25
サーバー管理者から害のあるスクリプトと認定されるものを走らせてアク禁くらって
まるでサーバー管理者側が悪いかのような口のきき方すれば
罵声を浴びるに決まってるだろ
人のことをとやかく言う前にまず自分のスキルを上げろって話さ
410:デフォルトの名無しさん
09/02/17 14:13:00
>>409
あっそ
411:デフォルトの名無しさん
09/02/17 14:58:21
>>410
うん
そういうこと
412:デフォルトの名無しさん
09/02/17 15:01:41
まあ普通にサーバ管理者に問い合わせれば済む話だしな。
413:デフォルトの名無しさん
09/02/17 18:00:16
一応書いておきますが、406と408、410は、別人です。
わたしは、どのみちシロウトです。
414:デフォルトの名無しさん
09/02/17 18:38:28
>>413の付け足しですが。
>>406は、ただ最後にちょっと気の利いたことを書いておこうと
思っただけです。
気に障ったらすみません。
でもネットには、けんかを買いたい人が待ち構えてるんだね。
>>408には、笑った。
415:デフォルトの名無しさん
09/02/17 19:40:55
ネットにはよそのサイトをDoSしても開き直っている奴いるしね。
416:デフォルトの名無しさん
09/02/17 20:31:15
もうやめて！>>361 のHPは０よ！
417:デフォルトの名無しさん
09/02/17 20:58:07
HPが0なら死ねよ
418:デフォルトの名無しさん
09/02/17 22:49:16
おまいら、また理解できないことが出てきちゃいました・・・
acceptで取得したソケットにはSourceAddressとPortが設定されています。
これはサーバーのAcceptAddressとPortです。
さらにacceptで取得したソケットにも同じアドレスがbindされています。
通常、複数のソケットに同じアドレスをbindする事はできないと思うのですが
なんでacceptはできるの？
プログラムで同じように複数のソケットに同じアドレスを
bindすることは可能なのですか？
正直使いたくてうらやましいです(´・ω・`)
419:デフォルトの名無しさん
09/02/17 23:01:40
同時じゃないんだからできるだろ
420:デフォルトの名無しさん
09/02/17 23:02:21
>>418
> 複数のソケットに同じアドレスをbind
されてはいないだろ。
> acceptで取得したソケット
はacceptしてるソケットとは別なんだから。
# TCPの接続は<srcIP, srcPort, dstIP, dstPort>の四つ組みで識別される。
421:デフォルトの名無しさん
09/02/17 23:12:26
>>419
すいません、何が同時じゃないんですか？(´・ω・`)
>>420
acceptで取得したソケットをbindしようとするとEINVALが返ってくるんだけど、
これはbindされてるって事じゃないんですか？(´・ω・`)
422:デフォルトの名無しさん
09/02/17 23:15:06
まじめに質問してるのであれば、顔文字やめろ
腹が立つ
423:デフォルトの名無しさん
09/02/17 23:17:58
>acceptで取得したソケットをbindしようとすると
んん？
424:デフォルトの名無しさん
09/02/17 23:29:31
>>422
すいません、マジメに質問してるので顔文字はやめます。
>>423
試しにやってみただけなんですけどEINVALが返ってきました。
bindされていると思った理由は
取得したソケットからgetsocknameでアドレスが取れるので
bindされてるのかなと思いました。
425:デフォルトの名無しさん
09/02/17 23:33:36
acceptに返された時点で「TCP接続」とbindされてる。
426:デフォルトの名無しさん
09/02/17 23:47:22
別に顔文字使ってもいいよ。真面目かどうかは内容で分かるから。
顔文字の有無で内容が変わって見えるような馬鹿なんかに初めから回答を期待しない方がいい。
427:デフォルトの名無しさん
09/02/17 23:54:31
>>424
TCP の 3way handshake を調べて、各 phase で何が渡されるか考えるのが吉
428:デフォルトの名無しさん
09/02/17 23:55:52
acceptで生成されたソケットのポートはリスナーのポートじゃねーだろ？
429:デフォルトの名無しさん
09/02/17 23:56:25
顔文字で判断なんて、ココロが広いな
「おまいら」などと言ってる時点で無視だよ
430:デフォルトの名無しさん
09/02/18 00:05:28
>>425
そのbindされたアドレスが他のソケットとかぶってるってことなんだけど
これはシステム上、srcAddressとPortがかぶるソケットがあっても
問題ないと自分は解釈したんだけど
accept以外にプログラムで同じことできないかなと思いました。
>>426
2chで顔文字怒られたのは初めてでした。
不快に思う人も居るって事で。
>>427
どうもです。
3way hand shake調べなおしてみます。
>>428
srcPortはリスナーのポートだと思います。
>>429
ごめんなさい。
431:デフォルトの名無しさん
09/02/18 00:31:36
(´・ω・`)おこんなよ
(´・ω・`)ちっちぇえな
432:デフォルトの名無しさん
09/02/18 01:00:53
>>430
APIで出来るのは、
接続してないソケットにsockaddrをbindすることだけです。
accept以外には、UDP等で使います。
433:デフォルトの名無しさん
09/02/18 01:20:57
>>431
煽るなよぅ
>>432
システム上できるけどAPIが提供されていないので出来ない
という解釈でいいんでしょうか。
あると便利なんだけどなあ・・・
434:デフォルトの名無しさん
09/02/18 01:28:41
便利じゃないです。良く勉強してください。
435:デフォルトの名無しさん
09/02/18 02:01:14
>>434
便利じゃないのか・・・
勉強してきます・・・
436:デフォルトの名無しさん
09/02/18 07:05:48
3way-handshakeが完了した時点で、
(クライアント：connect成功、サーバ：accept成功)
<sIP,dIP,sPort,dPort>の４つ組は決定するわけで、
そのあとで、「やっぱりポート変えたいんだけど」とか
TCP的にもありえないよね。
437:デフォルトの名無しさん
09/02/18 09:07:23
Acceptの返すのはTCP接続が確立したソケットだからね。
Acceptしているソケットは、接続のターゲットになっているわけだから、
同じsockaddrを持つソケットが複数存在しては、
接続要求をどこでこなせばいいか、kernelに分からない。
UDPソケットへの配送についても同様。
複数のソケットに同じsockaddrをbindする必要がない。
だから出来ない。してはいけないことだから出来ない。
438:デフォルトの名無しさん
09/02/18 22:12:34
>>436
確かにコネクションが完了した後に変更はありえないですね。
でも、それはbindのEINVAL（もうアドレスが設定してある）みたいにすれば
問題ない気もするんですけど、どうでしょう。
>>437
んー、確かに危険だとは思うのですが。
例えばソケットを2つ作って違う場所にconnectするとして
現状同じsrcAddrとPortをbindすることはできませんよね。
これができると使用するPortが少なくてすむかなと思いました。
少ないと何かいい事あるかどうかはアレですが・・・
439:デフォルトの名無しさん
09/02/18 22:15:00
>>436
FTP
440:デフォルトの名無しさん
09/02/18 22:20:16
>>438
「危険」なんて関係ない。
意味のないことだからできない。
無意味なAPIを提供する意味はない。
441:デフォルトの名無しさん
09/02/18 22:21:20
>>439
FTPはデータとコントロールが別接続。
データ接続は複数もって並列にやり取りできる仕様。
442:デフォルトの名無しさん
09/02/18 22:33:39
>>438
少しOSの身になって考えてみよう
> 例えばソケットを2つ作って違う場所にconnectするとして
> 現状同じsrcAddrとPortをbindすることはできませんよね。
外部から入ってきたデータを、 同じsrcAddrとPortを持ってるコネクションのうち、
どっちのコネクションに配送すればいいかを、どうやって決めたらいいんだ？
443:デフォルトの名無しさん
09/02/18 22:40:17
それを識別するために、TCP, UDP層の「アドレス」付加分として
新たにポート番号を付加して、配送先を一意に決められるようにしたのに、
30年近くたって>>418が突然、複数のソケットに付けられないのは不便じゃない？とw
郵便番号も複数の離れた土地に割り当てられたら便利かもね(棒読み)
444:デフォルトの名無しさん
09/02/18 22:59:12
初心者です。質問させてください。
<form action="sso-redirect" method="post" name="loginForm"> と書いてあるとき
、postメソッドで投げる先は URLﾘﾝｸ(sec-sso.click-sec.com)
で間違いないのでしょうか。 よろしくおねがいします。
445:デフォルトの名無しさん
09/02/18 23:00:30
初心者です。質問させてください。
URLﾘﾝｸ(sec-sso.click-sec.com)で表示されたhtmlに
<form action="sso-redirect" method="post" name="loginForm"> と書いてあるとき
、postメソッドで投げる先は URLﾘﾝｸ(sec-sso.click-sec.com)
で間違いないのでしょうか。 よろしくおねがいします。
446:デフォルトの名無しさん
09/02/18 23:07:48
>>440
やっぱりこれが一番の問題なんだろうな。
意味がないと理解できていないんですorz
>>.442
TCPだとacceptで取得したソケットはこれをやっていて
理由は>>420さんが書いてるように４組で識別しているからだと理解しています。
>>443
確かに、みんなこれでやってるのに疑問に思うのが問題ですよね・・・
何かの理解が足りていないと思われるorz
なんか長くなってしまったので、ここまでにしたいと思います。
色々勉強になりますた。
答えてくれた方々ありがとー♪
447:デフォルトの名無しさん
09/02/18 23:11:17
>>445
正しい場合が多いが、そうでない場合もある。<base>
448:デフォルトの名無しさん
09/02/18 23:13:55
TCP/IPのことで聞きたいのですがよろしいですか？
449:デフォルトの名無しさん
09/02/18 23:15:58
質問させていただきます。
450:デフォルトの名無しさん
09/02/18 23:16:36
>>448 なに？
451:デフォルトの名無しさん
09/02/18 23:17:23
TCPの接続を四つ組で一意に表すと考えたのは誰なんだろ。
うまいこと考えたもんだな。特に非対称の接続の時。
452:デフォルトの名無しさん
09/02/18 23:17:27
>>448
よろしいです。
453:デフォルトの名無しさん
09/02/18 23:21:01
これから10Mバイトの容量のデジカメ写真のデータをインターネット上の電子メールで送信しようとするところである。
10Mバイトと容量が大きいので、インターネット上をそのまま一つの10Mバイトのデータ送信する事ができない。
TCP/IPではこのデータをどのように分割して処理し、分割したデータのそれぞれが間違いなく送信の相手に届くように保証しているかIPとTCPの送信側、受信側それぞれの役割別に具体的に説明しなさい。
とあるのですが、まったくわかりません；
454:デフォルトの名無しさん
09/02/18 23:21:40
>>446
> 確かに、みんなこれでやってるのに疑問に思うのが問題ですよね・・・
つか、疑問に思った君は偉いと思うよ、マジで…
455:デフォルトの名無しさん
09/02/18 23:22:30
>>453
わからないのは、君のせいではなく、その文章を書いた人間がバカだからです。
「日本語でおｋ」と言ってやりなさい。
456:デフォルトの名無しさん
09/02/18 23:23:10
>>455
ΣΣΣ
単位がもらえなくな・・・ｒｙ
457:デフォルトの名無しさん
09/02/18 23:23:58
そんなバカから単位を貰う必要はない。
458:デフォルトの名無しさん
09/02/18 23:24:24
助けてください。
459:デフォルトの名無しさん
09/02/18 23:25:54
>>458 RFC 読めばいいと思うよ
460:デフォルトの名無しさん
09/02/18 23:27:32
>>459
拝見させていただきます。
461:デフォルトの名無しさん
09/02/18 23:28:58
日本語表記please。
462:デフォルトの名無しさん
09/02/18 23:32:56
>>453
バカな問題を好意的に解釈すると、
「分割」はIP、「間違いなく送信の相手に届くように保証」はTCPが行っている。
説明は下記を参照。
＠IT：連載 基礎から学ぶWindowsネットワーク 第10回 IPパケットの構造とIPフラグメンテーション 2．IPフラグメンテーション
URLﾘﾝｸ(www.atmarkit.co.jp)
＠IT：連載 基礎から学ぶWindowsネットワーク 第14回 信頼性のある通信を実現するTCPプロトコル（その1）
URLﾘﾝｸ(www.atmarkit.co.jp)
463:デフォルトの名無しさん
09/02/18 23:33:57
>>462
神様ありがとう。
464:デフォルトの名無しさん
09/02/18 23:38:11
僕に友達をくれて。
465:デフォルトの名無しさん
09/02/18 23:47:14
僕を妖精にしてくれて。
466:デフォルトの名無しさん
09/02/18 23:48:11
>>453
馬鹿な出題者が、解答者たちが、
TCPを真面目に勉強していることに大いに甘んじ、
出鱈目な言葉使いで、質問を出してる。
ところが、>>448はTCPの事はまるで勉強してないので
チンプンカンプンである。
これは馬鹿同士の衝突現象といえよう。
古典的なシェアードバスのEthernetコリジョンと同じである。
467:デフォルトの名無しさん
09/02/18 23:49:27
>>462
> 「分割」はIP
ちょww
468:デフォルトの名無しさん
09/02/19 00:19:19
ラスカルに会わせてくれて
469:デフォルトの名無しさん
09/02/19 00:33:15
ラスカルに会わせてくれて
470:デフォルトの名無しさん
09/02/19 10:58:32
ありがとう僕の友達
471:デフォルトの名無しさん
09/02/19 15:03:19
オスカルに会わせてくーれーーてー
472:デフォルトの名無しさん
09/02/19 15:12:23
>>471
この手の書き込みをする奴の精神構造が理解できない
473:デフォルトの名無しさん
09/02/19 15:52:50
同意
474:デフォルトの名無しさん
09/02/19 16:02:33
パスカルくらいにしとけば良かったのに。
475:デフォルトの名無しさん
09/02/19 16:26:27
GetIfTableでアドレステーブルを取得できますが、若い番号であるほど
優先順位が高い、という解釈であってますか？
476:デフォルトの名無しさん
09/02/19 17:45:43
bOrder
[in] Specifies whether the returned interface table
should be sorted in ascending order by interface index.
~~~~~~~~~~~~~~~~~
昇順ですな。
477:デフォルトの名無しさん
09/02/19 17:51:25
あ、そうだったのか！
今までユーザーに選択させてたよ
478:デフォルトの名無しさん
09/02/19 19:18:45
>462
TCPって、connection成立時にMSSが判るから、
IPのDFビットを立てたりするんだよね。
479:デフォルトの名無しさん
09/02/19 22:18:59
みんなUDPのサーバーってrecvfrom使ってるの？
ログインしたあと何回かやりとりするような仕様だと毎回recvfromでもらったアドレスからユーザー判別するのが
すごい無駄な気がするんだけどいい方法ないかな？
480:デフォルトの名無しさん
09/02/19 22:47:45
>>463-474
友達に聞いたんだけど
高校受験の時の面接で試験官が
突然ゴレンジャーの話をし始めたらしい
人生が懸かった試験だけに
どう対応して良いか分からなかったそうだけど
まともに相手をした受験生が落とされたらしい
481:デフォルトの名無しさん
09/02/19 23:11:41
単に頭が悪くて落ちた馬鹿が落ちたのをゴレンジャーのせいにしてるだけだろ。
482:デフォルトの名無しさん
09/02/20 00:09:29
>>479
そういう時はconnectするんだよ。
483:デフォルトの名無しさん
09/02/20 00:57:49
それってソケット新しく作ってconnectするってことだよね？
試したけどうまくいかなかったんだよなー
ちゃんとやればできるのか
もう一回チャレンジしてみる
484:デフォルトの名無しさん
09/02/20 04:46:12
サーバー側がacceptしてるときに、想定しているクライアントが接続してきたのか
流しのクライアントが偶然たどりついたのか、どうすれば判別できますか？
485:デフォルトの名無しさん
09/02/20 06:13:15
認証しろ
486:デフォルトの名無しさん
09/02/20 08:42:16
>>484
っcrypto
487:デフォルトの名無しさん
09/02/21 03:23:57
うまくいかないにゃー
488:デフォルトの名無しさん
09/02/21 16:30:19
ぬるぽ
489:デフォルトの名無しさん
09/02/21 17:30:21
>>480
がっこうなんて人生が懸かるような所じゃないよ
490:デフォルトの名無しさん
09/02/21 17:55:13
>>489
だれが上手いこと書けと
491:デフォルトの名無しさん
09/02/22 12:37:13
ガッ
492:デフォルトの名無しさん
09/02/22 13:07:48
>>491
>489がもう叩いてる
493:デフォルトの名無しさん
09/02/22 23:17:59
ちんこかゆい90円
494:デフォルトの名無しさん
09/03/03 00:09:49
ソケットインターフェースで（例えばrecvを使って）、たくさん流れてくるTCPのヘッダだけ読んで、ペイロードを読み捨てる（recvしない）ってことできる？
できるとしたら、どうすればいいの？
495:デフォルトの名無しさん
09/03/03 08:18:50
>>494
> ソケットインターフェースで（例えばrecvを使って）、たくさん流れてくるTCPのヘッダだけ読んで
Rawソケットでできる。
> ペイロードを読み捨てる（recvしない）ってことできる？
自分(ユーザー空間)で捨てるのが嫌だということなら、
カーネル内でプロトコルスタック書く必要がある。
496:494
09/03/03 10:30:27
>>495
つまり出来ないのね。ありがとう。
497:デフォルトの名無しさん
09/03/03 16:27:51
>>496
どうしても socket じゃないとまずいのか?
BPF とか pcap ライブラリ使ってフィルタするんじゃだめなのか?
498:デフォルトの名無しさん
09/03/03 21:23:29
>>497
まずくはないが、今はsocketインターフェースでの可能性を知りたい。
499:デフォルトの名無しさん
09/03/03 21:47:52
libpcapはソケット使ってるだろ。
500:デフォルトの名無しさん
09/03/03 22:58:00
OSによるんじゃね
501:デフォルトの名無しさん
09/03/04 22:32:32
RAW ソケットも Socket インターフェイスなわけだが。
502:デフォルトの名無しさん
09/03/04 23:11:20
RAWソケットじゃあ、ヘッダだけ読んで、ペイロードを読み捨てる（recvしない）ことは出来ないだろ。
読まないとヘッダかペイロードか判断できないし。
503:デフォルトの名無しさん
09/03/04 23:18:08
ちなみにRAWでやるってことはTCPのやりとりも自分で全部書くってことか？
捨てるだけでなく返事をせんと次のが来ないぞ。
504:デフォルトの名無しさん
09/03/04 23:24:22
誰に言ってるの？
505:503
09/03/05 00:00:10
>>504
>>>495-502
次ページ最新レス表示スレッドの検索類似スレ一覧話題のニュースおまかせリスト▼オプションを表示暇つぶし2ch
5394日前に更新/130 KB
担当:undef