ネットワークプログラ ..
2:デフォルトの名無しさん
09/10/14 03:45:45
過去スレ：
Port24 ｽﾚﾘﾝｸ(tech板)
Port23 ｽﾚﾘﾝｸ(tech板)
Port22 ｽﾚﾘﾝｸ(tech板)
Port21 ｽﾚﾘﾝｸ(tech板)
Port20 ｽﾚﾘﾝｸ(tech板)
Port19 ｽﾚﾘﾝｸ(tech板)
Port18 ｽﾚﾘﾝｸ(tech板)
Port17 ｽﾚﾘﾝｸ(tech板)
Port16 ｽﾚﾘﾝｸ(tech板)
Port15 ｽﾚﾘﾝｸ(tech板)
Port14 ｽﾚﾘﾝｸ(tech板)
Port13 ｽﾚﾘﾝｸ(tech板)
Port12 ｽﾚﾘﾝｸ(tech板)
Port11 ｽﾚﾘﾝｸ(tech板)
Port10 ｽﾚﾘﾝｸ(tech板)
Port9 ｽﾚﾘﾝｸ(tech板)
Port8 ｽﾚﾘﾝｸ(tech板)
Port7 ｽﾚﾘﾝｸ(tech板) ★行方不明
Port6 URLﾘﾝｸ(pc5.2ch.net)
Port5 URLﾘﾝｸ(pc2.2ch.net)
Port4 URLﾘﾝｸ(pc3.2ch.net)
Port3 URLﾘﾝｸ(pc3.2ch.net)
Port2 URLﾘﾝｸ(pc.2ch.net)
Port1 URLﾘﾝｸ(pc.2ch.net)
3:デフォルトの名無しさん
09/10/14 03:49:19
図書コーナー:
UNIXネットワークプログラミング〈Vol.1〉ネットワークAPI:ソケットとXTI
URLﾘﾝｸ(www.amazon.co.jp)
そのソースコード
URLﾘﾝｸ(www.unpbook.com)
詳解TCP/IP〈Vol.1〉プロトコル
URLﾘﾝｸ(www.amazon.co.jp)
詳解TCP/IP〈Vol.2〉実装
URLﾘﾝｸ(www.amazon.co.jp)
詳解TCP/IP〈Vol.3〉トランザクションTCP, HTTP, NNTP, UNIXドメインプロトコル
URLﾘﾝｸ(www.amazon.co.jp)
TCP/IPによるネットワーク構築
〈Vol.1〉原理・プロトコル・アーキテクチャ
URLﾘﾝｸ(www.amazon.co.jp)
〈Vol.3〉クライアント‐サーバプログラミングとアプリケーション
URLﾘﾝｸ(www.amazon.co.jp)
Linux/POSIXソケットバージョン
URLﾘﾝｸ(www.amazon.co.jp)
Windowsソケットバージョン
URLﾘﾝｸ(www.amazon.co.jp)
4:デフォルトの名無しさん
09/10/14 03:50:36
マスタリングTCP/IP RTP編
URLﾘﾝｸ(www.amazon.co.jp)
Linuxソケットプログラミング?ネットワークプログラミングにおける実践技法
URLﾘﾝｸ(www.amazon.co.jp)
Webプロトコル詳解?HTTP/1.1、Webキャッシング、トラフィック特性分析
URLﾘﾝｸ(www.amazon.co.jp)
WinSock2.0プログラミング
URLﾘﾝｸ(www.amazon.co.jp)
猫でもわかるネットワークプログラミング
URLﾘﾝｸ(www.amazon.co.jp)
IPv6ネットワークプログラミング
URLﾘﾝｸ(www.amazon.co.jp)
Visual Basicではじめるネットワークプログラミング超入門
URLﾘﾝｸ(www.amazon.co.jp)
5:デフォルトの名無しさん
09/10/14 03:51:18
URL抜粋:
★規格
RFC 日本語版リスト
URLﾘﾝｸ(www5d.biglobe.ne.jp)
JPNIC RFC関連リンク集
URLﾘﾝｸ(rfc-jp.nic.ad.jp)
RFC Editor
URLﾘﾝｸ(www.rfc-editor.org)
HTMLなRFC (セクションを直に示すのに便利)
URLﾘﾝｸ(www.freesoft.org)
RFC 2616 "Hypertext Transfer Protocol -- HTTP/1.1" 日本語訳
URLﾘﾝｸ(www.studyinghttp.net)
IANA Well known port numbers
URLﾘﾝｸ(www.iana.org)
6:デフォルトの名無しさん
09/10/14 03:52:13
★プログラミング
C10K ヘヴィーロードサーバ
URLﾘﾝｸ(www.kegel.com)
C10K ヘヴィーロードサーバ(日本語訳)
URLﾘﾝｸ(www.hyuki.com)
MSDN
URLﾘﾝｸ(msdn.microsoft.com)
Raw IP Networking FAQ
URLﾘﾝｸ(www.whitefang.com)
Java で packet capture
URLﾘﾝｸ(netresearch.ics.uci.edu)
Randomness Recommendations for Security
URLﾘﾝｸ(www.faqs.org)
BoostSocket
URLﾘﾝｸ(www.crystalclearsoftware.com)
The Code Project - Internet & Network programming
URLﾘﾝｸ(www.codeproject.com)
ネットワークプログラミングの基礎知識 (問題ありのサイト?)
URLﾘﾝｸ(X68000.q-e-d.net)
7:デフォルトの名無しさん
09/10/14 03:53:14
★ツール類
ethereal - URLﾘﾝｸ(www.ethereal.com)
Wireshark - URLﾘﾝｸ(www.wireshark.org)
tcpdump - URLﾘﾝｸ(www.tcpdump.org)
Windump - URLﾘﾝｸ(netgroup-serv.polito.it)
WinPcap - URLﾘﾝｸ(www.winpcap.org)
pathchar - fURLﾘﾝｸ(ftp.ee.lbl.gov)
pchar - URLﾘﾝｸ(www.employees.org)
Packetyzer - URLﾘﾝｸ(www.networkchemistry.com)
libevent - URLﾘﾝｸ(www.monkey.org)
★プロトコル
TTCP
URLﾘﾝｸ(www.sean.de)
URLﾘﾝｸ(www.kohala.com)
UDP Hole Punching
URLﾘﾝｸ(homepage3.nifty.com)
★IP, TCP実装
URLﾘﾝｸ(www.iti.fi)
URLﾘﾝｸ(www.sics.se)
URLﾘﾝｸ(www.codeguru.com)
URLﾘﾝｸ(www.geocities.jp)
8:デフォルトの名無しさん
09/10/14 06:56:20
>>1
乙
9:デフォルトの名無しさん
09/10/14 11:37:47
SCTPどーよ
10:デフォルトの名無しさん
09/10/14 21:10:47
Apacheの発見されていない脆弱性を教えてください＞＜
11:デフォルトの名無しさん
09/10/14 21:54:36
>>9
イーヨ
12:デフォルトの名無しさん
09/10/14 23:22:33
発見してしまった。
13:デフォルトの名無しさん
09/10/15 08:35:32
発見されていないのだから教える事はできない。
14:デフォルトの名無しさん
09/10/16 03:54:59
馬鹿に使われる、という潜在的な脆弱性は
ローカルでしか発見し得ないかも
15:デフォルトの名無しさん
09/10/16 13:16:40
実際大人になってからはじめてわかったことはいっぱいある
その殆どはわかったときには既に手遅れだったものばかりだ
16:デフォルトの名無しさん
09/10/17 18:22:06
高校生のうちにセックスしまくっとけとかなw
17:デフォルトの名無しさん
09/10/20 22:12:15
UDPで300BYTE程度のデータを送信しようとした所、送信できませんでした
1000byteなら送信できたのですが3000byteを送信しようとすると何か設定が必要なのでしょうか？
18:デフォルトの名無しさん
09/10/20 22:29:37
Windows の UDP パケット サイズの最大値は 1280 バイトが既定値
これ関係ある？
19:デフォルトの名無しさん
09/10/20 22:31:01
1280バイトと1281バイトで実験してみればいいだろ
20:デフォルトの名無しさん
09/10/20 23:32:16
18は17とは別人だお
UDPとか使わないから俺は実験しないお
21:デフォルトの名無しさん
09/10/21 00:34:44
エラーが起きた時はerrnoを調べるように頭の構造を設定する必要がある。
22:デフォルトの名無しさん
09/10/21 05:25:56
udpは親切に再送してくれないからな。受け取れない終わり出し。
23:デフォルトの名無しさん
09/10/21 05:50:45
つまり送信は性交していて受信が失敗してるわけですねわかります
24:デフォルトの名無しさん
09/10/21 05:55:10
否認したわけですね
25:17
09/10/21 07:50:19
3000byteのときは送信が成功しません。2000byteででもです。
1パケット以下なら送信が成功するのですが、そういう設定する
オプションってあるのでしょうか？
26:デフォルトの名無しさん
09/10/21 09:03:08
フラグメント有効なら通りそうな気もするが・・・
27:デフォルトの名無しさん
09/10/21 09:17:45
釣り針があまりにでかすぎる
28:デフォルトの名無しさん
09/10/21 13:51:17
ソケットプログラムを書いていたらある時ものすごいエラーが出るようになり、
原因を探っていたらどうもヘッダファイルのインクルード順序によって出るという結論に達しました
おおよそでも結構ですので、こういう順序でインクルードするとエラーが出にくいという方針などはあるのでしょうか？
29:デフォルトの名無しさん
09/10/21 15:37:02
要るものからインクルードするとエラーが出にくい
30:デフォルトの名無しさん
09/10/21 23:11:30
sys/types.hを最初に、それ以外はどうでもいい。
31:デフォルトの名無しさん
09/10/22 00:20:32
>>26
フラグメント有効ってどうすればよいのでしょうか？
カードの問題？
32:デフォルトの名無しさん
09/10/22 02:04:56
フラグメントはDoSに利用されやすいこともあって、
オフにしているところも結構ある。
頼らずに分割して送れ。
33:デフォルトの名無しさん
09/10/22 02:13:16
単にMTU越えてるから送れないってことじゃないの？
34:デフォルトの名無しさん
09/10/22 02:34:35
>>32
IP だとそうだけど, UDP のリアセンブルは IP とは別問題じゃないか?
とはいえ, IP フラグメント捨てられたら UDP がこけるのも事実だが……
そもそも, 元ネタが環境を書いてないのがよくない
35:デフォルトの名無しさん
09/10/22 02:38:48
殆どのバグは本人が問題無いと思っている場所にこそ存在する
36:デフォルトの名無しさん
09/10/22 07:23:31
>>34
> UDP のリアセンブル
何のことを言っているの?
37:デフォルトの名無しさん
09/10/22 08:04:23
UDPで1ﾊﾟｹ以上送ろうとするとﾌﾗｸﾞﾒﾝﾄ化されるけど、それがされなくてデータ自体送れなくなってるってことか
ﾌﾗｸﾞﾒﾝﾄ化のｵﾝｵﾌってどうやるんだったかな
38:デフォルトの名無しさん
09/10/22 08:36:44
分からない奴は加わってくるな
39:デフォルトの名無しさん
09/10/22 09:54:31
>>36
IPv6 は MTU ディスカバリー使って, 途中経路でフラグメント化されない形で
送信できるけど, v4 にはそうゆう機能がないのでフラグメント化される可能性
がある.
UDP は MTU 以上のデータグラムを送ろうとすると, 複数の IP パケットに分割して
送信される.
IP のフラグメントをリアセンブルするのと, UDP のデータグラムを複数の
IP パケットからリアセンブルするのは別の話だって言ってるんじゃないか
40:デフォルトの名無しさん
09/10/22 13:41:40
>>29 >>30
ありがとうございました
41:デフォルトの名無しさん
09/10/22 18:07:40
>>39
ん？
Path MTU DiscoveryはIPv4にだってあるだろ？
42:デフォルトの名無しさん
09/10/22 19:55:05
v6は必須だよね。
>>39
フラグメンテイションもリアセンブルも、
IP層で行われるのであって、上の層が何かは関係ない。
tcpdumpやfirewallみたいに層縦断する奴等は気にする必要があるが。
43:デフォルトの名無しさん
09/10/22 20:19:18
どっかのバカNEが「ICMP全部止めるのがセキュリティ」と妄信してるからなあ。
44:デフォルトの名無しさん
09/10/22 20:21:04
それじゃpingが通らんがなw
45:デフォルトの名無しさん
09/10/22 20:21:44
ping用のポートを用意
46:デフォルトの名無しさん
09/10/22 20:51:23
www.ntt.co.jpとか
47:デフォルトの名無しさん
09/10/22 22:30:32
>>44
The Internetにつながってるサーバはecho返さないようになってるの多くね？
48:デフォルトの名無しさん
09/10/22 23:07:44
結局、UDPで送信してもフラグメント化されないため送信されてないって話だろ
49:デフォルトの名無しさん
09/10/22 23:09:12
う、うん……(´・ω・｀)
50:デフォルトの名無しさん
09/10/24 14:23:18
listenの第2引数の意味がよくわからん
何にすればいいの
51:デフォルトの名無しさん
09/10/24 14:39:42
0-1
52:デフォルトの名無しさん
09/10/24 14:45:28
>>50
サーバ側がaccept(2)で接続確立するまで、
サーバ側に既に到着し待たされている接続要求をいくつ持てるか？
>>51
少なすぎて話にならない。
53:デフォルトの名無しさん
09/10/24 19:57:25
なるほどありがとう
54:デフォルトの名無しさん
09/10/24 20:12:46
ていうか、>>1のリンクくらい目を通せよ
55:デフォルトの名無しさん
09/10/24 20:14:07
1はバックログ数1というわけではないんだな。これが。
56:デフォルトの名無しさん
09/10/24 22:12:56
それはOSによる。
例えばLinuxは最小が8、最大はsysctl.max_syn_backlog
2の階乗にラウンドされる。
57:デフォルトの名無しさん
09/10/24 22:46:01
反論するなら、1がバックログ数1であるものを例示して反論してくれたまえ。
58:デフォルトの名無しさん
09/10/25 00:07:08
パケットのフラグメント化を許可する方法を教えてください
59:デフォルトの名無しさん
09/10/25 00:14:17
経路上の中継器の管理者にフラグメントされたパケットを落とさないように依頼する。
60:デフォルトの名無しさん
09/10/25 13:04:09
listenソケットて閉じちゃいけないの？問題発生したんだが
61:デフォルトの名無しさん
09/10/25 13:12:44
どんな問題か書け
62:デフォルトの名無しさん
09/10/25 14:05:12
セレクト使った場合
相手がクローズしたかどうかを知るにはどうすればいいの？
63:デフォルトの名無しさん
09/10/25 15:03:27
>>1のFAQ嫁
64:デフォルトの名無しさん
09/10/25 15:05:51
s.eof()
65:デフォルトの名無しさん
09/10/25 22:27:46
>>59
中継器は使用せず直接LANケーブルで送信受信側をつないでます
どうやらパケット自体送出できないみたいなのです
ﾌﾗｸﾞﾒﾝﾄ化が必要なデータだと
66:デフォルトの名無しさん
09/10/25 22:52:42
PS3かなにかのメッセージか？
動いてるなら気にスンナ
67:デフォルトの名無しさん
09/10/25 23:47:01
いえ、送出できてないので動かずです
68:デフォルトの名無しさん
09/10/26 00:25:23
>>58, 59
何がしたくて, 何をやったらどうなってるのよ？
どう言う意味でパケットのフラグメントを使ってるのよ？
IP フラグメントってのは, 下の例のような構成で,
中継が MTU=500 のネットに会わせて, 勝手に IP パケットを分割する
時の話だぞ
端点 -> MTU=1000 のネット -> 中継 -> MTU=500 のネット -> 端点
UDP で MTU 以上のデータを送信したいとかって話？
69:デフォルトの名無しさん
09/10/26 15:50:31
selectって条件が揃うまで値を返さないんだよね？
そうなるとrecvとaccsept用に２つスレッド作らないといけないのか？
70:デフォルトの名無しさん
09/10/26 16:17:26
recv用とaccept用のディスクリプタを両方セットしとけば、いずれか一方が読み込み可能になれば返ってくる
スレッドは1つでok
71:デフォルトの名無しさん
09/10/26 16:39:01
UDPソケット作る時に宛先アドレスを指定して作った場合も
sendto,sendmsgを使うなら宛先は指定しなければならないんでしょうか？
72:デフォルトの名無しさん
09/10/26 17:41:42
> UDPソケット作る時に宛先アドレスを指定して作った
作り方教えて
73:デフォルトの名無しさん
09/10/26 17:44:43
あー
勘違いしてました
74:デフォルトの名無しさん
09/10/26 18:24:38
UDPでもconnectしとけばsend/recv使えるよ
75:デフォルトの名無しさん
09/10/26 20:21:31
これからネットワークプログラムを開発する場合
今のトレンドのプログラム言語はなんでしょうか
76:デフォルトの名無しさん
09/10/26 20:22:20
Rubyだ
77:デフォルトの名無しさん
09/10/26 20:26:40
Javaだ
78:デフォルトの名無しさん
09/10/26 20:29:14
トレンドなんか気にしているようではいけない
79:デフォルトの名無しさん
09/10/27 00:12:51
>>68
すみません、UDPでMTU以上のデータを送りたいということです。
分かりにくくて申し訳ないです
80:デフォルトの名無しさん
09/10/27 00:54:01
>>79
OSとか環境とか情報はないのか?
sendto で宛先指定すりゃ普通に出ていかないか?
送れてない時ってエラー帰ってないか?
どうしても send が使いたいんだったら >>74
もっとも, 組み込み用のスタックとかだと UDP の
connect は, 実装してないスタックもあるらしいが…
81:デフォルトの名無しさん
09/10/27 06:19:11
>>79
送れません。
82:デフォルトの名無しさん
09/10/27 10:31:31
なんでRFCも読まずにネットワークプログラムしてる奴がゴロゴロいるんだ？
83:デフォルトの名無しさん
09/10/27 23:38:53
ICMP って 「アイコンプ」って読んだら変かなあ
84:デフォルトの名無しさん
09/10/27 23:54:47
hen
85:デフォルトの名無しさん
09/10/27 23:56:00
SNMPをスヌンプって読む人はいるよ
漏れは読まないけど
86:デフォルトの名無しさん
09/10/27 23:57:11
>>82
ﾉ
87:デフォルトの名無しさん
09/10/28 11:08:25
WSDLはうぃずどぅるだけどな
88:デフォルトの名無しさん
09/10/31 04:47:46
リフラグメント前提のパケットを大量に流してあげると、フラグメントしてくれる親切なルータにDoS出来てしまう気がした。これってセキュリティホールじゃ？
ICMP echoは捨ててもいいと思うけどね。ルータで捨てた時に送って来るICMPは捨てると良くないことが起きそうだが。
89:デフォルトの名無しさん
09/11/01 21:35:44
>>80
UDPのconnectなんてあるんですね。。でも、connectすりゃ、send,recv使えるって
しなくてもmtu以下のサイズなら使えます。そういうことではないのでしょうか？
OSがUNIXでもwindowsでもないからおくれないのかなぁ
90:デフォルトの名無しさん
09/11/01 21:47:16
connectしなかったらsendは使えない
だって宛先不明
sendtoやsendmsgは使える
connectしたらsendも使える
91:デフォルトの名無しさん
09/11/01 23:04:55
>>88
そんな古いDoS攻撃…
92:デフォルトの名無しさん
09/11/01 23:21:35
複数の接続を受けるサーバーを作りたいんだけど
人数が増えるたびrecvの回数増やすにはどうすればいいんだ？
93:デフォルトの名無しさん
09/11/02 00:37:19
recvの回数増やすというのはよくわからないが
受け付けた接続ごとに別々のスレッドを立ち上げるか
selectやpoll等を使ってひとつのスレッドですべての接続を捌くか
好きなほうを選べ
94:デフォルトの名無しさん
09/11/02 02:12:48
スレッドで処理してる間に、パケット届くと取りこぼしそうだw
95:デフォルトの名無しさん
09/11/02 02:37:43
はあ？
96:デフォルトの名無しさん
09/11/02 03:33:19
ＵＤＰパケットを取りこぼしなく取り込みたいのですが
なにかいい方法ありませんか？
97:デフォルトの名無しさん
09/11/02 09:59:52
あきらめれ
98:デフォルトの名無しさん
09/11/02 10:28:49
>>96
取りこぼさないのは無理なので、取りこぼしたことを検出して回復を図る
99:デフォルトの名無しさん
09/11/02 11:25:32
取りこぼしたくなければ素直にTCP使っとけ
UDPにするなら取りこぼしてもいいようにプログラム側を設計しろ
っていうのが定型文的な解答
100:デフォルトの名無しさん
09/11/02 15:29:39
決してしてはならないのは
「Ethernat直結でしか使わないからUDPでも取りこぼしなんて起きないだろう」
などと考えること。これをやってハマる初心者が意外に多くて困る。
101:デフォルトの名無しさん
09/11/02 16:09:27
同時にパケット発射すれば簡単に消えるしな。
102:デフォルトの名無しさん
09/11/04 18:16:51
マルチスレッド鯖製作中なんだけど
誰かからデータ受信したら送信してきた相手以外の
クライアントにそのデータを送るにはどうしたらいいの？
103:デフォルトの名無しさん
09/11/04 18:29:17
言葉どおりにやればいい
104:デフォルトの名無しさん
09/11/04 18:31:15
受信したことを別スレッドに通知するにはどうすればいいの？
105:デフォルトの名無しさん
09/11/04 19:14:21
通知を受け取りたい各スレッドごとにキューのようなデータ構造を何か用意する
通知を送りたいスレッドは宛先スレッドのキューに送りたいデータを置く
通知を受け取りたいスレッドはヒマなときに自分のキューを見てデータが来ていたら取り出す
OSによってはそういったメッセージキューの機能をすでに持っていることもある
自分で作る場合はスレッドセーフにすることを忘れずに
106:デフォルトの名無しさん
09/11/04 19:29:06
難しいこと考えないで、
受信したスレッドが全部のソケットに書けばいい
排他が気になるなら、ひとつmutexをロックしておけばいい
107:デフォルトの名無しさん
09/11/04 19:30:21
>>102
その質問そのものをコードにしてみればいいじゃないか(受け取ったデータを他に転送）
リソース競合には気をつける必要があるけど処理自体はおまいの質問そのものだぞ
108:デフォルトの名無しさん
09/11/04 19:32:41
>>102
何か効率の良い方法とか、そういうライブラリの存在を訊きたいのかもしれないが
そのレベルだとどちらの意味でもがんばって送信しやがれってレベルでしかないぞ。
109:デフォルトの名無しさん
09/11/04 22:04:39
>>106
スレッドに値渡ししたら次のアクセプトで変数上書きしてて
受信したスレッドは、送信する相手のソケットを知ることができないんだ
だから他のスレッドに通知してそのスレッドから送信させようかなと
グローバルの配列で管理しておかないとだめってことか
110:デフォルトの名無しさん
09/11/04 22:13:09
配列というか上に書いてある通りキューだろ
(キューの実装は配列でもいいけれど)
111:デフォルトの名無しさん
09/11/04 22:36:17
でもそれってrecvをノンブロックのしないといけないんでしょ？
112:デフォルトの名無しさん
09/11/04 22:56:51
そんなこと関係ない。
113:デフォルトの名無しさん
09/11/05 00:15:28
どういうこと
ノンブロックで受信とそのキューとやらのチェックをポーリングさせるってことじゃないのか
114:デフォルトの名無しさん
09/11/05 01:33:27
1接続しか許さないサーバプログラムを作る方法を教えてくだちい
listen()でバックログを1にしてaccept()した瞬間にlistenソケット閉じて
ってやればいいかと思ったけど
acceptする前にどんどん接続を受け付けやがる
115:デフォルトの名無しさん
09/11/05 02:47:46
接続待ち受けのソケットでそのまま通信すればいいんじゃね？
116:デフォルトの名無しさん
09/11/05 04:37:56
システムコールに惑わされずにまずRFC読め
117:デフォルトの名無しさん
09/11/05 08:47:12
同期用キューでも作って渡せばいい
詳しくはこっちだな
マルチスレッドプログラミング
ｽﾚﾘﾝｸ(tech板)
118:デフォルトの名無しさん
09/11/05 09:01:16
>>114
無理なOSは無理なんで諦めてください。
あらかじめ双方のポート番号が分かっているなら
双方からconnectって手があるけど。
119:デフォルトの名無しさん
09/11/05 09:02:35
>>113
お前がそう言う実装に拘る理由こそ、どういうこと？
120:デフォルトの名無しさん
09/11/05 09:29:30
>>114
キミのやりたい事は完璧にはできない。
バックログを0にして、acceptしたらlistening socketをcloseする。
これでもacceptしてからcloseするまでの間は接続を受け付けてしまう。
>>118
可能なOSを例示してくれ。今まで聞いたことが無いから知りたい。
121:デフォルトの名無しさん
09/11/05 09:41:41
昔のvxWorks
122:デフォルトの名無しさん
09/11/05 10:01:50
>>118
双方からconnectってなんだよ。
123:デフォルトの名無しさん
09/11/05 10:46:35
ポート食いつぶし攻撃か？
124:デフォルトの名無しさん
09/11/05 11:55:49
マイコンのプロトコルスタックを作ってる最中なのだがちょっと質問。
データ送信したとき全くの正常ならば
相手から返ってくるAcknoledgeNumber＝自分が送信したSequenceNumber＋TCPデータ長
となる筈なんだろうけど、この相手のACKパケットに入ってるAcknoledgeNumberが和より少ないときってこっちは何をすれば良いんだ？
もらったAcknoledgeNumberの分までは正常と見なして続きから送り直せばいいのかね？
125:デフォルトの名無しさん
09/11/05 15:25:59
>>124
そんなもんは気にせずに window size が 0 になるまで無理やり送りつけるんだ
126:デフォルトの名無しさん
09/11/05 17:43:56
マイコンに限らず再送バッファの大きさに支配されると思う
再送バッファサイズ＜＝窓までは送れる
127:デフォルトの名無しさん
09/11/05 22:18:00
>>126
最後は再送バッファサイズの問題とかスロースタートの問題には
行き当たるんだろうけど、プロトコル的には送ったもん勝だわな
128:デフォルトの名無しさん
09/11/06 02:03:33
>>122
host1: socket→bind→connect
host2: scoket→bind→connect
TCPの接続開始ハンドシェイクはこういうやり方でも可能。
129:デフォルトの名無しさん
09/11/06 22:03:48
意味が分からん。
ソースで示して＞128
130:デフォルトの名無しさん
09/11/07 13:54:24
横着しないで RFC 位読め
131:デフォルトの名無しさん
09/11/07 14:48:44
UDPって「取りこぼし」だけじゃなくて「送りそこね」もあるんだよな
132:デフォルトの名無しさん
09/11/07 16:41:10
途中で捨てられたも多い。取りこぼしだと届いてるのに拾えなかった感が有るが、そもそも届いてない。
133:デフォルトの名無しさん
09/11/08 21:50:24
Windowsでネットワークアドレスの違うIPアドレスへ強制的に
UDPのパケットを送る方法って無いでしょうか？
SetIpNetEntry（）で静的arpに登録して送っても駄目みたいでした。
（たぶん送信時に跳ねられている）
134:デフォルトの名無しさん
09/11/08 23:07:35
arpコマンドで登録すればいいんじゃ？
135:デフォルトの名無しさん
09/11/09 00:10:05
>>134
SetIpNetEntry()を呼ぶのと、arpコマンド実行は同じ事だと思うけど、
試しにpingとwireshark使ってやってみました。
Destination host unreachable.
と出て、相手には何も届いてないですね。
しかも、Windows7でやると特権がいるとかでエラーになるし、
諦めてブロードキャストで送ることにします。
136:デフォルトの名無しさん
09/11/09 08:54:56
ftpでファイルを送受信することになりました
こっちも相手側もクライアントとサーバになります
VC（MFC)でプログラムを作ろうと思いますが
どうやって作っていいかわかりません
クライアント側はサーバーに接続して
ファイルを転送する？イメージがあります。
検索するとCFtpConnectionをつかって作るのがわかりました
でもサーバー側ってどうやって作るんでしょうか？
どこかにサンプルとかヒントはありませんか？
137:デフォルトの名無しさん
09/11/09 09:38:23
ファイルが転送できればいいのかFTPプロトコルを実装したいのか
138:デフォルトの名無しさん
09/11/09 10:18:54
多分ファイル転送ができればいいです
プログラムでファイルをリモートのＰＣに送りたいのと
相手側がいつでもファイルをこちら側に送れるように
ｆｔｐサーバー機能があればいいです
139:デフォルトの名無しさん
09/11/09 10:21:10
>>133
違うネットアドレスへ送ろうとする場合、arpはgateway
に対してだよ？routeはどうなってるの？
140:デフォルトの名無しさん
09/11/09 10:39:50
>>138
では
URLﾘﾝｸ(www.geekpage.jp)
をちょこっと見ればできますね
141:デフォルトの名無しさん
09/11/09 11:07:33
>>140
ありがとうございます
見てみましたがｆｔｐについては見当たりませんでした
ｆｔｐサーバとしてｆｔｐクライアントの要望にこたえる例とかしりませんか？
142:デフォルトの名無しさん
09/11/09 11:10:23
サーバなんて既存のやつ使えばいいじゃない
サーバもクライアントも作るなら特定のプロトコルにこだわる必要もないだろう
143:デフォルトの名無しさん
09/11/09 11:11:38
だめだこりゃ
144:デフォルトの名無しさん
09/11/09 11:13:14
あとMFCならこういうのでどうか
URLﾘﾝｸ(www.codeproject.com)
145:デフォルトの名無しさん
09/11/09 11:18:28
>>142
一応売り物にするのでフリーのは問題ある？のではないかと思ってます
システムに組み込んで売っても問題ないフリーソフトとかありませんか？
>>144
ありがとうございます
参考にサンプル落とし見ようとしたら登録が必要なようですorz
英語はわからなくて…すみません
146:デフォルトの名無しさん
09/11/09 11:25:49
多少の英語も出来ずにプログラマやってるのかよ
147:デフォルトの名無しさん
09/11/09 11:28:01
もうRFC959読んで自前で実装しちゃいなよ
日本語訳もあったはずだ
148:デフォルトの名無しさん
09/11/09 11:48:47
>>145
BSDライセンスのFTPサーバ。FreeBSDのとか。
まあ機能限定で実装すれば自前でも簡単だけど。
149:デフォルトの名無しさん
09/11/09 11:54:27
>>148
ありがとうございます
ちょっと調べてみます
自分でいろいろ調べてたらXPにもｆｔｐサーバがあるみたいなのですが
XPのを使うのとフリーのｆｔｐサーバ使うのは全然違う意味ですか？
XP標準にあるならそっちのが楽なのかなぁ？と思ったりしてます
150:デフォルトの名無しさん
09/11/09 12:03:14
>>149
IISのこと?
151:デフォルトの名無しさん
09/11/09 12:04:52
IISはXPのProにはあるけどHomeには無いから気をつけて
152:デフォルトの名無しさん
09/11/09 12:09:04
>>150
そうです
XP Proを使う予定でｓ
153:デフォルトの名無しさん
09/11/09 17:17:07
初心者極まりない質問で申し訳ないですが、お願いします。
VB6.0のwinsockオブジェクトを用いて、出来合いのサーバ（ORCA_CLAIM)に
データを送信するプログラムを作成してます。
ポートとアドレスを指定して送りたいデータを送信し、
ただクローズするだけなのですが、送信後にサーバのステータスが
CLOSE_WAITになったまま消えてくれません。
(# netstat -nap localhost などで確認）
そうなると再送信してもﾎﾟｰﾄが現在使用されていますと出て、
ｴﾗｰを返すのでとても困っています。
サーバソフトの製作元にもたずねて見ましたが、そんな現象はありえないと
いうお話でしたので、どうもこちら側に決定的な原因があるようです。
状況説明がうまくないようでしたら申し訳ありません。
何か、ありがちなミスなどありましたらご指摘よろしくお願いします。
154:デフォルトの名無しさん
09/11/09 17:41:20
winsock1.closeはしてるの？
155:デフォルトの名無しさん
09/11/09 17:51:47
IISに投げてみたけどCLOSE_WAITにはならないよ
Option Explicit
Private Sub Command1_Click()
Winsock1.LocalPort = 0
Winsock1.RemoteHost = "localhost"
Winsock1.RemotePort = 80
Winsock1.Connect
End Sub
Private Sub Winsock1_Close()
Winsock1.Close
End Sub
Private Sub Winsock1_Connect()
Winsock1.SendData "GET / HTTP/1.0" & vbCrLf & vbCrLf
End Sub
Private Sub Winsock1_DataArrival(ByVal bytesTotal As Long)
Dim s As String
Winsock1.GetData s
MsgBox s
End Sub
156:デフォルトの名無しさん
09/11/09 18:47:40
同じ質問を過去に見たんだが、解決方法忘れてしまった
VBスレの人なら知ってる人いるんじゃない？
157:デフォルトの名無しさん
09/11/09 19:29:30
>>153です。皆様レスをつけていただいて有難うございます。
>>154
うーん。Winsock1.closeはやっているのですが、反応がないようです。
>>155
すいませんサンプルソースまで書いてもらって、助かります。
私のソースもだいたいそのような感じなのですが、見直してみることにします。
>>156
有力情報有難うございます。
そちらの方にも尋ねてみることにします。
158:デフォルトの名無しさん
09/11/09 20:08:45
>>157
どちらが先にクローズする仕様なの？
159:デフォルトの名無しさん
09/11/09 23:25:49
レス有難うございます。
>>158
URLﾘﾝｸ(www.orca.med.or.jp)
の（２）によると、送信した側がsocket closeと書いてあるようですので
こちら側（送信側）がCloseしなければいけないのかなと考えています。
160:デフォルトの名無しさん
09/11/09 23:38:25
closeする前にサーバのACK/NAK応答は受信したのかと
161:デフォルトの名無しさん
09/11/09 23:41:31
言っとくがTCPじゃなくてアプリレイヤーの話だぞ？
>>159のシーケンスをちゃんと嫁
162:デフォルトの名無しさん
09/11/09 23:45:18
見落としてるだけだろ
アホとしか
163:デフォルトの名無しさん
09/11/10 00:01:16
>>159
これだとCloseイベントでcloseしたほうがいいかもしれない。
>>155のように
164:デフォルトの名無しさん
09/11/10 00:32:37
closeしなくてもほっときゃ切れるだろ
165:デフォルトの名無しさん
09/11/10 01:37:03
socketは全二重
送る側だけまずshutdown
読む側でEOFまで全て読み終わるのを確認してからclose
これはちゃんとやって
166:デフォルトの名無しさん
09/11/10 09:17:58
皆様何度も返信してくださって
厳しいながらもありがたい限りです
>>160
そちらの受信は確認しております。
>>161
アプリレイヤーとTCPの違いがまだよく分かっていないのですが、
そこの部分は調べてみます
>>163
ちょっとその手法でやってみます
>>165
shutdownはwinsockメソッドにはなく、
URLﾘﾝｸ(www.int21.co.jp)
で見ました。全文読んでいないのでなんともいえませんが、
まだ使い方が不明なので調査してみます。
167:デフォルトの名無しさん
09/11/10 23:40:54
>>166
> shutdownはwinsockメソッドにはなく、
何言ってるかわからない。
書く側だけまずshutdownしろってのは、
winsockのFAQの初心者向け項目に書いてあること。
168:デフォルトの名無しさん
09/11/10 23:47:48
良くこれで仕事が出来るな・・・
169:デフォルトの名無しさん
09/11/11 00:04:43
とりあえずWiresharkで
双方の FIN → FIN,ACK → ACK のどこまで出てるか見てみたら？
170:デフォルトの名無しさん
09/11/11 05:43:11
サーバの開発元に質問するほうもアレだが、ありえないと回答するのもひどいな。
お互い良くそれでプログラマって言えるよな。
171:デフォルトの名無しさん
09/11/11 18:13:12
IdBaseComponent,
IdComponent,
IdTCPConnection,
IdTCPClient,
IdHTTP
IdException
このへんのコンポーネントってIndyですか？
172:デフォルトの名無しさん
09/11/11 18:18:28
Indyですね
173:デフォルトの名無しさん
09/11/11 18:27:53
>>172
ありがとう
IdってIndyって意味だったのか
コンポーネントないからビルドできねぇ
174:デフォルトの名無しさん
09/11/11 23:35:50
>>153
> CLOSE_WAITになったまま消えてくれません。
サーバ側のCLOSE_WAITは全く関係ない。お前の作ったクライアントがダメなだけ。
> 何か、ありがちなミスなどありましたらご指摘よろしくお願いします。
自分のバグを他人の所為だと思いたがる態度が、初心者にありがちな重大なミス。
bindしてるだろ。
175:114
09/11/12 01:33:52
>>120
やっぱ無理だよな、ありがとう
>>118
相手がわかってればいいんだけどねぇ
176:デフォルトの名無しさん
09/11/12 07:44:31
>>128
それじゃ3-wayハンドシェイクが成立しないだろ。可能だと主張するなら動作するサンプルコードを。
177:デフォルトの名無しさん
09/11/12 08:50:27
>>176
RFC に双方 connect() 時のシーケンス載ってるが?
178:デフォルトの名無しさん
09/11/12 09:01:03
>>176
RFC793 の figure 8 だけど、rfc1122 でその図の間違
いが訂正されてる。
4.2.2.10 Simultaneous Open Attempts: RFC-793 Section 3.4, page
32
There is an error in Figure 8: the packet on line 7 should
be identical to the packet on line 5.
A TCP MUST support simultaneous open attempts.
DISCUSSION:
It sometimes surprises implementors that if two
applications attempt to simultaneously connect to each
other, only one connection is generated instead of two.
This was an intentional design decision; don't try to
"fix" it.
179:デフォルトの名無しさん
09/11/12 09:25:14
> This was an intentional design decision; don't try to "fix" it.
うわっ、強引。決めたんだからなおすな。
180:デフォルトの名無しさん
09/11/12 09:37:37
>>179
違う違う。「実装者は双方同時 open の結果として一つ
しかコネクションが出来ないことに驚くかもしれないが、
これはそうなるように『設計』されているので直そうと
するな」ということ。
181:デフォルトの名無しさん
09/11/12 10:28:32
コネクションが2つでなく1つなのは「そのように決めたんだからなおすな」って事でしょ。
なんで、そのように決めたんだろう。
という事は置いておいて、これは同時にconnectが発生した(例外的な)場合に関しての
規定であって、>>118が言ってるような狙ってできるってもんじゃないよね。
182:デフォルトの名無しさん
09/11/12 10:29:35
>>174
>自分のバグを他人の所為だと思いたがる態度が、初心者にありがちな重大なミス
逆に自分のせいだと思って散々調べたら自分のせいじゃ無かったってのもよくある
まずは切り分けが大事と思い知らされた
183:デフォルトの名無しさん
09/11/12 10:44:42
>>181
> 狙ってできるってもんじゃない
普通は RST が返るからってこと?
184:デフォルトの名無しさん
09/11/12 11:05:05
>>181
＞なんで、そのように決めたんだろう。
同じIPアドレス、ポート番号のペアを持つコネクション
は同時に複数存在できませんから。
185:デフォルトの名無しさん
09/11/12 11:18:53
一方のコネクションが確立した後では、1本のコネクションにはならないでしょ。
186:デフォルトの名無しさん
09/11/12 11:22:01
>>184
なるほど、接続するという選択肢を取るならそのように決めるしかないわけか。
接続しないという選択肢もあったわけだけど、そっちは採用しなかったと。
187:デフォルトの名無しさん
09/11/12 22:30:35
双方がwell knonw portになってから接続を開始しているわけだから、
四つ組みが決定している。一つの接続になるのが、設計上当然の帰結。
>>183
いや再送されたのと区別がつかない。
(IPタイムスタンプオプションとかない限り)
それに普通のOSではREUSEADDRしたら、
前のは無効になる。
188:デフォルトの名無しさん
09/11/13 10:31:37
よくわからないレベルで仕事って確実に地雷だなw
189:デフォルトの名無しさん
09/11/13 11:26:24
結局サンプルコードはまだ？まさか>>128じゃないよね
190:デフォルトの名無しさん
09/11/13 12:06:33
RFCだけ読んで「キリッ」って奴がいかに多いか分かるな
実際のコーディングはまったくできないと。
191:デフォルトの名無しさん
09/11/13 12:24:58
自分が仕事出来ないのを棚に上げて人のせいにする奴もいるしな
192:デフォルトの名無しさん
09/11/13 14:55:17
rfcも実際のコード実装例を描いてくれればいいのだがな。
そういうサイト作ると需要有るのか？
193:デフォルトの名無しさん
09/11/13 15:25:53
>>189
> まさか>>128じゃないよね
>>128 で何か不足してる?
TCP/IP の同時 open は、よくある TCP/IP の状態遷移
図で通常サーバ側とクライアント側で違う経路を通ると
ころを両方ともクライアント側の遷移を通るんだから
>>128 であってる。
スティーブンス本のどれかで実際のプログラムと実行例
が載ってたよ。但し、双方の SYN が交差する位には充
分に遅い経路を使う必要があったと思う。
194:デフォルトの名無しさん
09/11/13 16:24:19
>>193
listenしなくて良いのか?
195:デフォルトの名無しさん
09/11/13 16:35:49
>>194
> listenしなくて良いのか?
listen したら駄目なんだけど?
196:デフォルトの名無しさん
09/11/13 16:48:04
ほい、スティーブンス本での同時 open の話と実行例。
URLﾘﾝｸ(books.google.com)
上で使われてる sock プログラムのソースコード。
URLﾘﾝｸ(www.icir.org)
listen() を呼び出している servopen() は -s オプショ
ンが無いと実行されないけど上の例では -s ついてない
でしょ。
197:デフォルトの名無しさん
09/11/14 00:43:24
cygwinでsockコマンドコンパイルしてlocalhostでやってみたけど、
確かに同時に実行するとconnect成功するね
・・・同時に実行しなければ繋がらないってのは、ちょっと面白いな
198:デフォルトの名無しさん
09/11/14 17:23:34
遂にgoogle booksを参照する時代になったか。
199:デフォルトの名無しさん
09/11/14 17:31:32
結局、元質問(>>114)を実現する事はsocketプログラミングの範囲ではできないという結論だね。
200:デフォルトの名無しさん
09/11/14 18:08:03
できるだろ。釣りかよw
201:デフォルトの名無しさん
09/11/14 18:23:33
listenの実装を自分で書き換えればいいだろ
202:デフォルトの名無しさん
09/11/15 00:05:59
>>200
動作するサンプルを。
203:デフォルトの名無しさん
09/11/15 01:21:09
>>201
socket.h内のSOMAXCONNを1にしたらひどぅい目に遭いましたｗ
実装の書き換えまで手を出すのは正直無理ぽですね。
204:デフォルトの名無しさん
09/11/16 04:45:47
URLﾘﾝｸ(x68000.q-e-d.net)
このページを参考に1回connectに成功したらaspxファイルのヘッダとボディのデータを
分けて要求するプログラムを作ったのですがボディのデータを要求するとコネクションが切断されているのかread関数が0を返します。
close関数を使っていなくても1回データを要求したら切断されてしまうものなのでしょうか。ソースは次のレスに記載します。
205:デフォルトの名無しさん
09/11/16 04:48:30
char path[100],buf[1000],host[]="www.nurupo.jp";
struct hostent *servhost;struct sockaddr_in server;struct servent *service;int s,read_size;
servhost = gethostbyname(host);bzero(&server,sizeof(server));server.sin_family = AF_INET;
bcopy(servhost->h_addr,&server.sin_addr,servhost->h_length);server.sin_port = htons(80);
s = socket(AF_INET,SOCK_STREAM,0);connect(s,(struct sockaddr *)&server,sizeof(server))
sprintf(path,"HEAD /gga.aspx HTTP/1.0\r\n\r\n");
write(s,path,sizeof(path));
while(1){
read_size = re ad(s,buf,sizeof(buf));
if(read_size > 0){write(1,buf,sizeof(buf));}
else{
break;}}
sprintf(path,"POST /gga.aspx HTTP/1.0\r\nContent-Length: 10\r\n\r\nnurupo=gga\r\n\r\n");
write(s,path,sizeof(path));
while(1){
read_size = read(s,buf,sizeof(buf));
if(read_size > 0){write(1,buf,sizeof(buf));}
else{break;}}
close(s);
206:デフォルトの名無しさん
09/11/16 05:00:41
>>204>>205です。
if(read_size > 0){write(1,buf,size_of(buf))}
の行のsize_of(buf)はread_sizeでした。
すいません…
207:デフォルトの名無しさん
09/11/16 05:42:52
HTTP/1.0
RFC1945
1.1は2616
208:デフォルトの名無しさん
09/11/16 09:05:10
>>204-205
HTTP/1.0はそのように決められている。
HTTP/1.1ではPersistent Connectionsというのがあるが、使い方はかなり難しい。
209:デフォルトの名無しさん
09/11/16 09:17:41
別に難しくは無いさ。
リクエストとレスポンスを交互に繰り返すだけであれば。
終端だって、どうやって判断すればよいかちゃんとRFCに書いてある。
chunkの読み出しも、そのまま実装するだけ。
210:デフォルトの名無しさん
09/11/16 11:04:36
嘘つきサーバが多いから難しい。
211:デフォルトの名無しさん
09/11/17 02:24:14
テスト
212:デフォルトの名無しさん
09/11/17 15:47:40
>>204です。
お返事ありがとうございます。
RFC2616やグーグルしたところ、HTTP/1.1はHost: URLを記述しなければいけないとのことだったので
記述し、2回目のデータ要求ではConnection: Closeを記述したところ2回、データを要求することが出来ました。
2回目はBad Requestになってしまいますが。。
RFCを見て、少しやる気をなくしてしまいましたが
出来たらネットワークの勉強に励み、この問題をいつかは解決したいと思います。
ありがとうございました。
次ページ最新レス表示スレッドの検索類似スレ一覧話題のニュースおまかせリスト▼オプションを表示暇つぶし2ch
4822日前に更新/115 KB
担当:undef