ネットワークプログラ ..
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を見て、少しやる気をなくしてしまいましたが
出来たらネットワークの勉強に励み、この問題をいつかは解決したいと思います。
ありがとうございました。
213:デフォルトの名無しさん
09/11/20 00:14:01
UDPのブロードキャストについて質問です
pythonとCで書いてます。(例はpythonで書きます)
ブロードキャストでデータを送りたいのですが、
setsockoptでSO_BROADCASTを有効にし、
# pythonの例
sock.sendto( data, ( "255.255.255.255", 1234 ) )
としても、受信側で受信できません。
# 受信側のIPアドレスは192.168.11.4
sock.sendto( data, ( "192.168.11.4", 1234 ) )
として、ユニキャストだと受信できることを確認しています。
環境はlinuxです。
ブロードキャストアドレスとして255.255.255.255を使うのは間違ってますか？
214:デフォルトの名無しさん
09/11/20 03:25:47
それは自分の所属するサブネットの中なの？外なの？
215:デフォルトの名無しさん
09/11/20 06:15:52
>ブロードキャストアドレスとして255.255.255.255を使うのは間違ってますか？
はい
216:デフォルトの名無しさん
09/11/20 07:06:20
rootにならないとできないとかそういうのもあるよね。
217:デフォルトの名無しさん
09/11/20 08:36:47
ブロードキャストアドレスとして192.168.11.255と設定してあるだろ。
それ使えよ。
218:デフォルトの名無しさん
09/11/20 13:28:28
基本的にネットの負荷が上がるのでブロードキャスト非推奨。
つ ブロードキャストストーム
輻輳を検知するとポート綴じちゃうスイッチも有るよ。
219:デフォルトの名無しさん
09/11/20 18:32:47
>>214
自サブネット内です。
>>215
はい
ありがとうございます
>>216
rootになっても変わりませんでした。
>>217
確かに/24で切ってるので、192.168.11.255も試したのですが変わりませんでした。
ハード的におかしいのかと思い、
192.168.11.4を持つマシン上で、サーバとクライアントを動かしたのですが、
結局受信しませんでした。
wiresharkでみるとパケットは観測されてたのですが・・・
220:デフォルトの名無しさん
09/11/20 18:44:37
promiscus
221:デフォルトの名無しさん
09/11/20 19:02:55
× promiscus
○ promiscuous
222:デフォルトの名無しさん
09/11/20 23:24:41
>>219
受信側はどうバインドしてるの？ 例えば'192.168.11.4’にバインドしてたらそのアドレスへのユニキャストしか受信出来ない。 ブロードキャストも受け取りたいならアドレスは'' （空文字列）でバインドしなければだめ。
223:デフォルトの名無しさん
09/11/21 19:20:27
空文字列？
192.168.11.255にバインドするべきじゃないの？
224:デフォルトの名無しさん
09/11/21 19:21:12
どうみても 0.0.0.0 にバインドです本当にありがとうございました
225:デフォルトの名無しさん
09/11/21 19:39:22
まったく知識がないんだがどこから手をつければいいのか教えろカスども
226:デフォルトの名無しさん
09/11/21 19:50:51
.255なんて使うなよw
227:デフォルトの名無しさん
09/11/21 19:56:40
まずお前が何をしたいのか教えろよカスが
228:デフォルトの名無しさん
09/11/21 19:57:53
SEXしたい；；
229:デフォルトの名無しさん
09/11/21 20:06:44
おまえら！
N88ベーシックの時代を思い出せ！
使ってるだけじゃだめなんだよ！
利用者全員がプログラマーにならなきゃ世の中は良くならない！
そうだろうみんな！！
230:デフォルトの名無しさん
09/11/21 20:07:39
食いっぱぐれます
231:デフォルトの名無しさん
09/11/21 22:21:39
せんせー
IPアドレスからgethostbyaddrでホスト名とってくるプログラムをVC++（まあなんでも出来るが）で組んだのだけれど、
もし取ってこれなかった場合
＞初回の例外が発生しました: 0x000006BA: RPC サーバーを利用できません。
みたいなのが出力パネルに無視して平気？
一応host名がNULLだった時の退避路はあるし、エラーでプログラムが止まるわけじゃないんだけど
なんかわざわざ一回づつ排出するもんだから気になって
232:デフォルトの名無しさん
09/11/21 23:24:51
try catch
233:デフォルトの名無しさん
09/11/22 02:37:25
これかな
URLﾘﾝｸ(support.microsoft.com)
234:デフォルトの名無しさん
09/11/24 19:49:11
ソケット生成してbindした時点で、データが送られてくると
受信はされるのでしょうか？
そこから、recvformで取り出すといった感じなのでしょうか？
データを一定間隔で送信し、送信した結果複数の個所からデータが返ってくる
とした場合、最初に返ってきたデータだけをデータとして取り込みたいのですが
こういった場合、どうするのが最適でしょうか？
235:デフォルトの名無しさん
09/11/24 20:32:30
bindってよく考えたら、0.0.0.0でbindしておけば
自分のIPが192.168.11.4でも recvfromで192.168.11.100 宛のデータも受信できるのでしょうか？
（ポート等は同じで、ARPで関連づけておくとして）
236:デフォルトの名無しさん
09/11/24 20:44:28
promiscuous
237:デフォルトの名無しさん
09/11/24 21:35:41
promiscuous は関係ない
238:デフォルトの名無しさん
09/11/24 21:42:51
それより質問の仕方が悪い
239:デフォルトの名無しさん
09/11/24 22:43:16
通常のモードだと自分のMAC宛のパケットしか受信できない
240:デフォルトの名無しさん
09/11/24 22:56:11
>>239
ARPテーブル操作して、自分のmac向けに別のIPを関連づけたら届きますよね
そこで0.0.0.0をbindしておけば自分の今のIPとは違うデータまで受信できるということでしょうか？
241:デフォルトの名無しさん
09/11/24 23:30:36
>>240
MAC判別はネットワークチップの機能だよ
242:デフォルトの名無しさん
09/11/24 23:37:24
>>241
すみません、よくわかってないのですが
MAC判別がどう関係あるのでしょうか？
宛先mac自体は、本来の宛先macをarpテーブルで指定してやりますよね
243:デフォルトの名無しさん
09/11/24 23:42:42
送信する相手のARPテーブルを操作するって事か
それが受信できるかどうかはIP層の実装仕様次第じゃないのか？
普通は出来ないと思うが・・・
244:デフォルトの名無しさん
09/11/24 23:51:53
変なパケットは捨てるのが基本
245:デフォルトの名無しさん
09/11/25 00:00:49
実装仕様とはNICに依存するのでしょうか？
でもmacアドレスはあってる、IP層のIPも送信元がARPテーブル操作してあってる
から届くはずだとはおもうんですが
246:デフォルトの名無しさん
09/11/25 00:52:43
> ARPテーブル操作して、
どこのマシンのARPテーブルいじる気だよ。毒入りarp投げるのか?
オレの管理下で発見したら接続禁止だぞ。上司が土下座しなけりゃつなげさせない。
> そこで0.0.0.0をbindしておけば自分の今のIPとは違うデータまで受信できるということでしょうか？
IPってゆうな。クズ。
例え送信元のARPテーブル操作してパケットが届いたとしても出来ない。
0.0.0.0は自マシンのアドレスに対するワイルドカードだからだ。
もう一回言っておく。IPってゆうな。クズ。
247:デフォルトの名無しさん
09/11/25 01:18:53
受信したいマシンが 192.168.11.100 というIPを持っていないから無理
RawIPでも使え
248:デフォルトの名無しさん
09/11/25 01:28:28
IPってゆうな。クズ。
249:デフォルトの名無しさん
09/11/25 01:37:02
単にアドレスって言うのもハンパだろ？
250:デフォルトの名無しさん
09/11/25 01:45:49
IPアドレスを省略するときは単に「アドレス」って言う
IPは知的財産の省略形として稀に使うぐらい
251:デフォルトの名無しさん
09/11/25 02:01:57
ネット盗聴ソフトか不正アクセスでもするソフトでも作ってるのかw
252:デフォルトの名無しさん
09/11/25 03:27:17
>>235
環境による
>>240
環境による
253:デフォルトの名無しさん
09/11/25 06:53:48
promiscuous
254:デフォルトの名無しさん
09/11/25 07:32:45
>>246 >>247
>>252
さんがいうには、環境によってはできるとのことですが
255:デフォルトの名無しさん
09/11/25 07:33:57
俺の自作スタックなら何でも出来る
256:デフォルトの名無しさん
09/11/25 08:02:59
>>252
かなりめずらしい環境でないか？ 組み込み系のマイナーな
スタックとか？
257:デフォルトの名無しさん
09/11/25 17:54:55
WinSockのWSAAsyncSelectについて質問です。
今まで使い方を間違えていたらしく、あちこちのサンプルでは
(1)
リスニングソケットにはFD_ACCEPTを設定し
WSAAsyncSelect(socketListen, hWnd, (WM_APP + 1), FD_ACCEPT))
(2)
case FD_ACCEPT内で
SOCKET socket = accept(m_sckListen, &addr, &nLength);
WSAAsyncSelect(socket, hWnd, (WM_APP + 1), FD_READ | FD_CLOSE)
と、個別にFD_READやらFD_CLOSEを設定するのが正解のようです。
今まで私は(1)で FD_ACCEPT | FD_READ | FD_CLOSE と設定し、(2)ではWSAAsyncSelect自体を呼び出していませんでした。
ですが、この状態でもsocket側に通信データが送られてきた際に、きちんとwParam == socketな状態でWD_READが呼び出されていました。
これは、正規の仕様に乗っ取った挙動なのでしょうか？
例えば「リスニングソケットにFD_READなどを設定しておくと、そのリスニングソケットでacceptされたソケット全部にFD_READが自動的にセットされる」とかでしょうか？
258:デフォルトの名無しさん
09/11/25 18:11:24
asyncも分かってないしselectも分かってないな
259:デフォルトの名無しさん
09/11/25 20:36:58
ソケット生成してbindした時点で、データが送られてくると
受信はされるのでしょうか？
そこから、recvformで取り出すといった感じなのでしょうか？
データを一定間隔で送信し、送信した結果複数の個所からデータが返ってくる
とした場合、最初に返ってきたデータだけをデータとして取り込みたいのですが
こういった場合、どうするのが最適でしょうか？
260:デフォルトの名無しさん
09/11/25 20:48:26
スタックって自作できるのでしょうか？
スタックを自作すれば、L1レベルから入ってきたデータを好きなように取り込めるのでしょうか？
261:デフォルトの名無しさん
09/11/25 21:07:50
IEの仕様書はどこにありますか
MicroSoftのサイトの情報見ても全然かゆいところに手が届かない
262:デフォルトの名無しさん
09/11/25 21:23:21
>>259
TCPだとそうだね。acceptしてからだけど。
他のは捨てたいって事なら読んでから捨ててクローズすればいい。
読まずに捨てたいってことなら、それはやらない方がいい。
理由はFAQ読んで。上にも話題に出てる。
263:デフォルトの名無しさん
09/11/25 21:24:03
>>260
> スタックって自作できるのでしょうか？
あなたの能力次第。
264:デフォルトの名無しさん
09/11/25 21:25:05
>>259
お前はまずProgramming UNIX Socket FAQを全部嫁。
>>260
できないと思うのなら、それはお前の知識が無いからだ。
>>261
ないんじゃないの？何が知りたいの？
265:264
09/11/25 21:25:51
うお、かぶりまくったぜ。
266:デフォルトの名無しさん
09/11/25 22:10:46
>>264
FAQよんだのですが、bindした時点でデータがきているかはのってないのですが
267:デフォルトの名無しさん
09/11/25 22:38:57
>>266
自覚して無いかもしれないが、日本語に難ありすぎて意味不明
268:デフォルトの名無しさん
09/11/25 22:42:18
おそらく
「bindしたあと、recvfromをする前に到着したメッセージは
全て、その後の recvfrom で読み出せるのか？」
と質問したいんだろう
269:デフォルトの名無しさん
09/11/25 23:10:46
>>260
BSDのドライバのソースを読む
Linuxはダメ！絶対
270:デフォルトの名無しさん
09/11/26 09:12:07
257です。
＞「リスニングソケットにFD_READなどを設定しておくと、そのリスニングソケットでacceptされたソケット全部にFD_READが自動的にセットされる」
これが仕様に基づく正しい動作であることを、英語版MSDNページで確認しました。
271:デフォルトの名無しさん
09/11/26 11:52:31
こんな何の情報もくれないスレに、律義だなぁ
272:デフォルトの名無しさん
09/11/26 11:55:16
Arduinoとイーサネットシールドを勉強すれば
プロトコルスタックも作れるよ
273:デフォルトの名無しさん
09/11/27 00:25:46
IE8に導入されたInPrivateブラウズって、保存済みのクッキーすら読み込んでくれないん？
クッキーは保存してあるのにリクエストに含まれてこない。
本家サイトみても、”新しくクッキーを保存することはないよん”としか書いてなくてよくわからん。
274:デフォルトの名無しさん
09/11/27 07:14:43
c+winsockでHTTPプロキシ作ろうとしてるんだが
ブラウザから送られてきたhostヘッダの部分を接続先にして
データを受け流す、みたいな感じでいいのか？
その場合httpsの通信はどうするの？
275:デフォルトの名無しさん
09/11/27 07:50:13
hostヘッダがないときでも相手につながないといけないわけだが
276:デフォルトの名無しさん
09/12/01 22:58:35
ブロードキャストで送信しているソケットで、受信もしていて
そのソケット宛に、VBのwinsockでブロードキャストで送信しようとすると
ローカルコンピュータからは利用できませんとエラーがでたり、
二つのパソコン用意して、同様にVBからHUBを介してそのソケット宛にデータ送ろうとすると
片方はブロードキャストでおくれるのだが、もう片方はデータすらおくれない
同じネットワークにブロードキャスト送信できる数とかに制限あるのかな
277:デフォルトの名無しさん
09/12/02 00:39:07
TCP/IPにはそのような制限はない。
WinsockやVBについては知らないので他の人お願い。
278:デフォルトの名無しさん
09/12/02 00:50:18
知らないなら黙ってればいいのに
279:デフォルトの名無しさん
09/12/02 04:36:18
そりゃブロードキャストで送ればネットワークに負担がかかるし、不要なPCにもパケット送りつける事になってしまうからなあ。
280:デフォルトの名無しさん
09/12/02 13:41:20
だから何だよ？
281:デフォルトの名無しさん
09/12/02 15:18:33
ブロードキャストって何？
282:デフォルトの名無しさん
09/12/02 17:14:15
放送
283:デフォルトの名無しさん
09/12/02 19:57:05
PC-HUB-PC でUDPにてお互い同時に周期的に送信していて、たまにパケットが喪失するのですが
これってどんな原因が考えられますか？
284:デフォルトの名無しさん
09/12/02 20:16:18
気にする方向を間違えている
その件に関して我々は原因を追究するべきではない
285:デフォルトの名無しさん
09/12/02 20:24:28
>>283
天使の取り分
286:デフォルトの名無しさん
09/12/02 21:46:07
udpでもtcpでもパケットは消失するものなんだよ。
tcp: osがどうにかしてくれる。
udp: 自分でどうにかするか諦める。
287:デフォルトの名無しさん
09/12/02 21:52:35
ただ、HUBを介して単純に超近くのネットワークなのに、他にそのパソコン以外通信なし
でも頻繁に損失するものなのかなーとおもいまして
何回に1回とか大体の確率っておおよそでいいからわかるのかなぁ
288:デフォルトの名無しさん
09/12/02 21:56:49
消失が完全に予測出来るなら暗号に使えるな
289:デフォルトの名無しさん
09/12/02 22:01:07
LAN側に古いハブ使ってるがコリジョンランプがガンガンつきまくってる
仕組みはよくわからんが、よく通信できてるもんだと関心するほどだ
290:デフォルトの名無しさん
09/12/02 22:51:42
HUBを介すのと介さないのでは喪失しやすくなったりするのかね
291:デフォルトの名無しさん
09/12/02 23:15:48
お互いに交互に投げ合ってるならぶつからないだろうけど
同時に投げてるならぶつかるんじゃないのか？
292:デフォルトの名無しさん
09/12/03 00:03:33
交互に投げ合っててもいつか同時のタイミングが発生しそうな
293:デフォルトの名無しさん
09/12/03 00:11:30
CSMA/CDか
久しぶりに思い出したんで忘れかけてたよ
294:デフォルトの名無しさん
09/12/03 00:22:50
>>290-292
お前等スイッチングハブの「スイッチ」の意味知らないだろ。
パーフェクトシャッフルとかバタフライネットワークとか。
295:デフォルトの名無しさん
09/12/03 00:25:44
なにはともあれ、今つかってるバカハブは捨てるべきだな。俺。
末端のTVとDVDレコ用だけど・・・
296:デフォルトの名無しさん
09/12/03 00:36:53
PC−PC のように単純にケーブル１本でお互い送受信していても
UDPならパケットの衝突か消失がありうるということ？
297:デフォルトの名無しさん
09/12/03 00:44:04
何がおこってもおかしくはない
ノイズやバッファオーバーなど色々あるんじゃない？
UDPがそれらに保障されてないんだから、プログラマとしてはそれを考慮してプログラムを組むしかない
298:デフォルトの名無しさん
09/12/03 00:50:43
>>296
ループバックインターフェースでも消失はありうる。
299:デフォルトの名無しさん
09/12/03 01:00:56
>>297
バッファオーバーはデータのサイズを小さくもてば少なくなるのかなぁ
ノイズでそんなに頻繁になくなるのかな PC-PCとかでも
１分間に１０回ほど消失するって大きい？
300:デフォルトの名無しさん
09/12/03 01:20:10
今では低速なRS232Cでも電気的に失敗することはある
クロックだのなんだの、下位の仕事してたころにはこれでいいのかなと疑問に思いながら作ってたもんだ…
もちろん通信の失敗を考慮してプログラムしてたが
301:デフォルトの名無しさん
09/12/03 01:52:47
今時ノイズは余り関係ない。イーサネットで距離も短ければ。
302:デフォルトの名無しさん
09/12/03 02:02:47
プログラム組む側としては、そんな話はどうでもいいんだって。
303:デフォルトの名無しさん
09/12/03 02:05:58
距離も短くノイズも関係ないとすればたかだがPC間伝送でパケット消失する理由って・・・
304:デフォルトの名無しさん
09/12/03 02:10:04
バッファなりなんなり能力以上の処理が必要になれば当
然パケットは落ちる。忙しい状況は自分のプログラムと
は無関係に発生するかも知れない。TCP は再送する。
UDP は再送しない。
305:デフォルトの名無しさん
09/12/03 08:35:33
バカハブは貴重品だぞ。
簡単には手に入らないが価値をしらないバカの手元にあるのはもったいない。
306:デフォルトの名無しさん
09/12/03 09:22:54
スニファ作るとか？
307:デフォルトの名無しさん
09/12/03 09:24:49
開発用にリピータハブ重宝しております
308:デフォルトの名無しさん
09/12/03 11:12:41
>>299
ping 1時間くらい投げ続けてlossどれくらい？
309:デフォルトの名無しさん
09/12/03 17:30:01
初歩的な質問ですいません。
よくある「"ABCDEFGH"と送信しても"ABC""DE""FGH"と3回で受信されることもある」という例ですが、
この例は送信がTCP/UDPレベルで計3パケットに分割されたということなるのでしょうか？
310:デフォルトの名無しさん
09/12/03 17:31:36
送信かもしれない
途中の道かもしれない
受信かもしれない
311:デフォルトの名無しさん
09/12/03 17:33:06
逆に2回にわけて送ったやつがくっついてることもある
312:デフォルトの名無しさん
09/12/03 19:10:15
既にクローズされてるソケットにclosesocket使ったらエラーで強制終了される？
313:デフォルトの名無しさん
09/12/03 19:25:44
エラーだが強制終了されない
314:デフォルトの名無しさん
09/12/03 22:20:48
>>309
UDPならAPIレベルでは分割されないよ。
データグラム通信を提供するサービスだから。
315:デフォルトの名無しさん
09/12/04 00:44:49
何か障害出まくるアプリケーションが多いのがよくわかるスレだ。
絶対はないから、ちゃんと回避手順を考えてプログラム組むべき。
エラーになったらどうするのか。想定してなかったので、そのまま終了じゃゴミ。
316:デフォルトの名無しさん
09/12/04 22:21:18
オーストリッチアルゴリズム最強
317:デフォルトの名無しさん
09/12/11 00:06:40
プロキシを作りたいのですが
どうやって作ればいいのでしょうか？
書籍とかあれば教えてください
318:デフォルトの名無しさん
09/12/11 00:09:04
プロ棋士？
319:デフォルトの名無しさん
09/12/11 00:10:07
どのような情報を盗み見たいの？それによって作り方変えないと
320:デフォルトの名無しさん
09/12/11 00:17:04
>>319
透過プロキシ+多層です
321:デフォルトの名無しさん
09/12/11 00:20:31
>>319
サイバー犯罪幇助で通報しますた
322:デフォルトの名無しさん
09/12/11 02:48:29
つまり勝手にパケット横取りしてナニしたいと。
323:デフォルトの名無しさん
09/12/11 03:10:33
誰かが串通して児ポとかダウンロードした日には死ねるなｗ
324:デフォルトの名無しさん
09/12/11 03:24:38
透過プロキシ - Google 検索
URLﾘﾝｸ(www.google.co.jp)透過プロキシ
325:デフォルトの名無しさん
09/12/11 09:08:36
URLﾘﾝｸ(homepage2.nifty.com)
326:デフォルトの名無しさん
09/12/11 12:47:22
recvに渡した最大受信バイト数を超えるデータを受け取ると
文字列が途切れて文字列操作に支障が出ることがあるんだが
バッファサイズデカくするしか無いの？
327:デフォルトの名無しさん
09/12/11 12:49:03
最大受信バイト数を超えるデータを受信するわけないじゃんｗ
328:デフォルトの名無しさん
09/12/11 17:31:06
>>326
n回受信→連結 してから操作しちゃだめなん？
多分 TCP だと思うが、
分割されることだって（1回の send なのに 受け側は recv 2回になった）あるし
まとまることだって（2回の send が、受け側は recv 1回でまとまって読めた）ある
329:デフォルトの名無しさん
09/12/11 19:04:45
>>326
バッファサイズをでかくするか、
自分でバッファリングするなりしてやらないとダメだよ
330:デフォルトの名無しさん
09/12/11 22:14:24
proxyってどうやって作るの？
331:デフォルトの名無しさん
09/12/11 22:31:27
そんなレベルの人には関係ありません
332:デフォルトの名無しさん
09/12/11 23:39:31
アプリケーション層じゃなくて
なんとか層とかいうレベルの処理をするんだっけ？
333:デフォルトの名無しさん
09/12/11 23:43:08
そうかお前らスキル低いから答えられないのか
それなら仕方ないな
334:デフォルトの名無しさん
09/12/11 23:45:25
はいはいそうでちゅよ〜
335:デフォルトの名無しさん
09/12/12 00:13:27
中途半端に教えたところでレベルの低い人間には無意味だしね
336:デフォルトの名無しさん
09/12/12 00:35:31
UDPのrecvfromで、サイズを指定しますよね
そのサイズって、たとえば１４００バイトのデータが送られてきて
recvfromの引数でサイズを４００で指定してやると、４００バイトだけ
バッファにため込みますよね
残りの１０００バイトはどうなるのでしょうか？
次にrecvfromしたときに４００バイトだけそこからまたよみこむのでしょうか？
337:デフォルトの名無しさん
09/12/12 00:40:06
yes
338:デフォルトの名無しさん
09/12/12 00:40:47
嘘を教える奴は最低な奴だと思う
339:デフォルトの名無しさん
09/12/12 01:02:15
>>336
残りの1000バイトは粉みじんになって死んだ・・・
340:デフォルトの名無しさん
09/12/12 01:04:35
では、１４００バイトのデータが２回に分けて連続して送信されてきました。
2回送信されたあとに、recvfromで４００バイト読んだとすると、
残りのデータはすべて消えるのでしょうか？
あるいは、３０００バイト読めば全て読めるということでしょうか
341:デフォルトの名無しさん
09/12/12 01:07:44
せめて試してから質問しろよな
342:デフォルトの名無しさん
09/12/12 01:08:57
>>340
1回目の送信が1000バイト、2回目が400バイトだったとしよう。
1回目を400バイトのバッファで受信したら、残り600バイトはパァだ。
2回目の400バイトは・・・おめでとう、すべて受信出来たな。
343:デフォルトの名無しさん
09/12/12 01:09:54
recvfrom 受信バイト - Google 検索
URLﾘﾝｸ(www.google.co.jp)受信バイト
344:デフォルトの名無しさん
09/12/12 01:10:10
>>343
Opera使いか？
345:デフォルトの名無しさん
09/12/12 01:13:52
>>1-7のテンプレは読んだのか？
346:デフォルトの名無しさん
09/12/12 01:14:35
>>345
イミフ
347:デフォルトの名無しさん
09/12/12 04:10:17
ipは途中でルータが処理するの辛く成ったら捨てていいよって通信手順だしな。
届かなきゃ、再送するしか無い。まあ再送しまくると余計にルータが辛く成って捨てられるけどなw
お利口なルータは捨てたら一応icmpで通知はしてくれる。ファイヤウォールとかでicmp捨ててたら当然届かないけどw
348:デフォルトの名無しさん
09/12/12 11:14:57
>>342
バッファって、どこのバッファですか？
349:デフォルトの名無しさん
09/12/12 12:07:31
>>348
あなたがデータを受け取るためにrecvfromの第2引数に指定したバッファ
350:デフォルトの名無しさん
09/12/12 12:34:01
UDPのカーネル内での受信バッファサイズって
どこで規定されてたっけ？defineとかあった？
あと、これは勉強不足から来る質問なんだけど
IPv6でも65536-20-8=65516が最大サイズでおｋ？
351:デフォルトの名無しさん
09/12/12 15:40:03
>>349
ありがとうございます
ただ、１０００バイトと４００バイトのデータが送られてきて
ソケットのバッファ？にたまってますよね
それをrecvfromで４００バイトずつ取り出すと、残り６００バイトが
パーになるとのことですが、
どうやってrecvfromは、１回目の１０００バイトと２回目の４００バイトを
別として見分けるのでしょうか
352:デフォルトの名無しさん
09/12/12 15:43:23
UPDの仕様は理解したうえでの質問なんだよな？
353:デフォルトの名無しさん
09/12/12 15:43:57
ソフトを作る団塊で通信するパケットサイズ決めておくんじゃね？
354:デフォルトの名無しさん
09/12/12 15:45:55
>>351
取り出したらああああああああああああああｓｓｓｓｓｓｓｓ
見分けるというか、パケット単位で管理してる。
recvfromでパケットごとに取り出すので
取り出す際に余った分は破棄される
355:デフォルトの名無しさん
09/12/12 15:52:28
そもそもUDPなの？
356:デフォルトの名無しさん
09/12/12 15:58:18
どうせ釣りだろ
357:デフォルトの名無しさん
09/12/12 18:07:41
ほんとにTCP/IPの知識ないのにネットワークプログラミングやろうとする奴多すぎ
358:デフォルトの名無しさん
09/12/12 18:10:11
やれば知識がつくんだからいいじゃない
359:デフォルトの名無しさん
09/12/12 18:11:57
プロトコル層とかなんちゃら層とか
360:デフォルトの名無しさん
09/12/12 18:24:35
>>351
> どうやってrecvfromは、１回目の１０００バイトと２回目の４００バイトを
> 別として見分けるのでしょうか
>>354 が言う通りパケット毎に管理してる。
そもそも recvfrom() は引数で送信元アドレス／ポート
が取得できるだろ。連続して違う相手から受信したらデー
タが混じるとでも思ってるのか?
361:デフォルトの名無しさん
09/12/12 19:46:46
65536-20-8=65508だったな。計算間違えたぜ。
このサイズ以上はOS側で落とされるな。
362:デフォルトの名無しさん
09/12/12 21:04:26
proxyの作り方教えてください
363:デフォルトの名無しさん
09/12/12 21:13:42
proxy 作り方 - Google 検索
URLﾘﾝｸ(www.google.co.jp)作り方
364:デフォルトの名無しさん
09/12/12 21:14:06
>>360
recvfromがまとめてパケットを１回でとりこむかなとおもいまして・・・
そういう部分は、recvfromの関数がソケットと関連づけられてつくられてるのかな
365:デフォルトの名無しさん
09/12/12 21:24:48
他のプログラムが使用してるソケットにデータを送ることってできないの？
某ネトゲチートツールみたいに
366:デフォルトの名無しさん
09/12/12 21:38:12
>>365
自分で答えを書いているじゃないか。
367:デフォルトの名無しさん
09/12/12 21:47:59
p2proxyみたいに
368:デフォルトの名無しさん
09/12/12 23:20:21
>>365
Windows? Linux？
Linuxなら結構簡単
369:デフォルトの名無しさん
09/12/15 21:34:53
自作したプログラムで（おそらく）存在しないURLにアクセスすると
３０００回くらいで、ネットワーク自体から切断されます
ISPにも問い合わせましたが、このプログラムを止めてくれと言うだけで
原因がはっきりしません
ループ文使って sprintf( http, "URLﾘﾝｸ(....%d.jpg)", i );
とURLを作ってるのですが
なにかしらの暗黙のルールなどあるのでしょうか？
WindowsAPI使ってます
370:デフォルトの名無しさん
09/12/15 21:48:30
ISP側に同情するわ
371:デフォルトの名無しさん
09/12/15 21:55:11
>>369
阿呆かお前は
ネットワークプログラムのテストするなら
まずはローカルで試してからだろボケ
致命的なバグを抱えているかも知れんのに
常識を疑われてもしょうがないレベルだな
372:デフォルトの名無しさん
09/12/15 22:01:37
sprintfで外に出ていってしまうん？
373:デフォルトの名無しさん
09/12/15 23:24:59
おまえは何を行っているんだ
374:デフォルトの名無しさん
09/12/16 00:31:54
連番jpgを物故抜きしてんのか？
ネットランナーでも買っとけ
375:デフォルトの名無しさん
09/12/16 00:39:10
>>369
> 原因がはっきりしません
しとるがなw
376:デフォルトの名無しさん
09/12/16 01:07:36
DoSアタックと判断されて蹴られてると考えるのが普通だな
俺が管理者なら攻撃とみなしてISPに通報するね
377:デフォルトの名無しさん
09/12/16 01:11:33
IPS(ISPじゃないよ)で自動的に切断です。
378:デフォルトの名無しさん
09/12/16 01:14:44
IPS インターネット プロバイダ サービス
ISP インターネット サーバー プロトコル
379:デフォルトの名無しさん
09/12/16 02:42:06
>>378
無知を晒して楽しいか？
380:デフォルトの名無しさん
09/12/16 07:19:11
preventionなのかprotectionなのか
381:デフォルトの名無しさん
09/12/16 07:23:39
脳内返答ばかりやな
役に立たんゴミども
382:デフォルトの名無しさん
09/12/16 09:44:38
んなこといったって、状況説明がほとんどないんだから脳内補完して答えるしかねーだろ
とりあえずどうせ、1鯖へのコネクションは同時に2本まで。というルールすら守ってないんだろ・・・
383:デフォルトの名無しさん
09/12/16 09:51:31
負荷下げるためにkeep-alive使ったり、それで性能がほしければ
パイプライニングしたりするべきだが...
384:デフォルトの名無しさん
09/12/16 12:02:10
まあうざいのはdenyされるので、がんばっても無理だけどな。
相手の許容範囲で出来る事を遣るしか無い。
385:デフォルトの名無しさん
09/12/16 15:34:03
>>382
>同時に2本まで。というルールすら
>>369 に、「同時にコネクション張る」甲斐性があるとは思えません。
386:デフォルトの名無しさん
09/12/16 16:44:19
問い合わせたお（＾ω＾）
テンプレが返ってきたお（；ω；）
お問合せいただきました事象によるネットワークからの切断に
つきましてですが、大変申し訳ございませんが弊社で判断する
ことは困難な状況です。
うんこ様のご利用いただいております電話回線に関しまして、通常時に
故障などが発生した場合には、フレッツサービスに関するお問合せ先が
ございますので、下記フリーダイヤル番号までご連絡いただきますよう
よろしくお願い致します。
とりあえず、コネクション２つ以上とかアホ言ってるやつは士ね
387:デフォルトの名無しさん
09/12/16 17:04:16
サムライ呼ばわりとは是如何に
388:デフォルトの名無しさん
09/12/17 00:38:13
ファイヤーウォールみたいに通信に割り込みかけるのってどうやるの？
389:デフォルトの名無しさん
09/12/17 03:17:17
ちょっと待ってて
390:デフォルトの名無しさん
09/12/17 09:10:01
架空URLに高速連続問い合わせとか、DNS鯖に対する攻撃か・・・？
警告はおろか、実際に査察が来るレベルだぞ
391:デフォルトの名無しさん
09/12/17 11:23:39
友人がPING（のようなもの）を飛ばしまくって、JPNICからリアル警告くらってたな
その話聞くまで都市伝説だと思ってたよ俺も
392:デフォルトの名無しさん
09/12/17 11:25:58
信用できねぇ
393:デフォルトの名無しさん
09/12/17 11:40:10
>>392
一般的に考えるとJPNICからってのが胡散臭い感じがするけど
それが本当なら恐らくmrtgみたいなことしようとして主要IXとかに
pingしまくって怒られたって話なんじゃないかと。
394:デフォルトの名無しさん
09/12/17 11:45:15
むちゃな事をしなけりゃ一生縁の無い話なんだから、どうでもいいなｗ
395:デフォルトの名無しさん
09/12/17 12:10:06
どうでもいい
396:デフォルトの名無しさん
09/12/17 12:34:03
昔はTCPのスタックの負荷テストするのにテキトーなサイトの
chargenポートに繋いだもんだったw
397:デフォルトの名無しさん
09/12/17 12:41:22
（自慢話は）どうでもいい
398:デフォルトの名無しさん
09/12/17 12:41:54
パソコン通信の時代はプログラム的にはどう接続してたの？
たしか相手先の電話番号にダイヤルアップで直に接続してたんだよね？
399:デフォルトの名無しさん
09/12/17 12:46:20
モデムのシリアル接続で直に。基本はテキストのみ。
バイナリをやりとりする時は XMODEM その他のプロトコルで。
400:デフォルトの名無しさん
09/12/17 13:03:50
相手ＰＣとの同期とかどうしてたの？
401:デフォルトの名無しさん
09/12/17 13:04:55
図書館とかで古いパソコン雑誌見るとパソコン通信の電話番号とかたくさん掲載されててなんかすごかったわｗ
402:デフォルトの名無しさん
09/12/17 13:07:13
同期もなにも、相手のデータを引っ張り出すだけだからなぁ
telnetとかわらん感じだが
403:デフォルトの名無しさん
09/12/17 13:09:02
なるほど。細かいところはハードウェアかＯＳあたりが処理してたのか。今と変わらんのか。
今でもやろうと思えばパソコン通信ってできるの？
404:デフォルトの名無しさん
09/12/17 13:09:33
>>400
モデムの上位は無手順。
基本はデータをただ流すだけだけど、
スタートビット、ストップビット、パリティビットなどの取り決めがある。
405:デフォルトの名無しさん
09/12/17 13:11:12
ｵｻｰﾝが多いことだけはわかった
406:デフォルトの名無しさん
09/12/17 13:12:03
>>404
そのビットとかはプログラム側で処理するの？
407:デフォルトの名無しさん
09/12/17 13:14:21
RS232C(COM)プログラムしてみりゃわかる
ただ設定をちょこっと命令するだけ
次ページ最新レス表示スレッドの検索類似スレ一覧話題のニュースおまかせリスト▼オプションを表示暇つぶし2ch
4823日前に更新/115 KB
担当:undef