[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 2chのread.cgiへ]
Update time : 04/27 09:35 / Filesize : 234 KB / Number-of Response : 958
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

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



1 名前:デフォルトの名無しさん mailto:sage [2010/12/25(土) 22:46:56 ]
主にソケットに関しての質疑応答スレッドです。

Programming UNIX Socket FAQ (日本語訳)
www.kt.rim.or.jp/~ksk/sock-faq/indexj.html
Winsock Programmer's FAQ (日本語訳)
www.kt.rim.or.jp/~ksk/wskfaq-ja/

関連リンクは>>2-10辺り
足りなかったら適当に付け足してね

前スレ
ネットワークプログラミング相談室 Port26
hibari.2ch.net/test/read.cgi/tech/1269343909/
関連スレ
ネットワークプログラミング雑談
hibari.2ch.net/test/read.cgi/tech/1235800707/
Java ネットワークプログラミング 【教えて!】
hibari.2ch.net/test/read.cgi/tech/1086238859/

357 名前:デフォルトの名無しさん mailto:sage [2011/06/19(日) 10:18:30.45 ]
ていうか宇宙と通信するのに通信路が複数ある可能性は無いよね。

358 名前:デフォルトの名無しさん mailto:sage [2011/06/19(日) 11:13:24.80 ]
>>357
「宇宙と通信」は >>352 が言う通り意味がよくわからんが、
はやぶさは3本の通信路を持ってたよ。

て言うか通信路1本だけって、怖すぎだろ。

359 名前:デフォルトの名無しさん mailto:sage [2011/06/19(日) 11:46:10.75 ]
>>358
3本もあったのか・・・
1本は直通だとして、残りの2本はどことどこ経由?
やっぱ火星のアンテナ経由するのかな

360 名前:デフォルトの名無しさん mailto:sage [2011/06/19(日) 11:46:37.88 ]
100mbpsでも物理想は4本の撚り線使ってた気がするけど。

361 名前:デフォルトの名無しさん mailto:sage [2011/06/19(日) 13:03:19.73 ]
>>359
直通って...、流石に宇宙と通信しようとしてる奴は違うな (w

マジレスしとくと、低利得アンテナ (8bps)、中利得アンテナ (32bps)、
高利得アンテナ (4Kbps) の3系統。

362 名前:デフォルトの名無しさん mailto:sage [2011/06/19(日) 13:27:30.68 ]
>>356
>>357
>>358
>>359
>>360
おお、皆さんありがとうございます。
僕が思ったのは、惑星間航行が普通に行われるようになっても
これだけ普及したIPという仕組みは無くならないと思うんですよね。
でも、TCPだとちょっと?機能が足らないと思ったんですよ。

パケットの送信に何十分もかかる状態なら、
いっそパケットを多重化してしまえば再送が必要ないんじゃないかなと。

別チャネル?にしたらいいんじゃないかなと思ったのは、
通信路が複数有ったら一本磁気嵐とかでデータが飛んでも
リカバリできるんじゃないかなと。

どちらかというと絶対確実に届くUDPの方が近い気がしてきた。

そういう仕組みって誰も考えたことないのかなぁ。

ガンダムとかだと、
AMBACとか細かい設定まで有るのに。
まぁ、あの世界だとニュータイプがいるからいいのかな。


363 名前:デフォルトの名無しさん [2011/06/19(日) 13:54:57.28 ]
>>362
先ずはIPとかTCPとかよりもっと低位層のが問題では?

364 名前:デフォルトの名無しさん mailto:sage [2011/06/19(日) 13:55:27.15 ]
>>362
> どちらかというと絶対確実に届くUDP

色々考えるのはいいことだと思うが、まず基礎からちゃんと勉強して
おくことをお勧めする。

でないと、まともな人から相手されなくなるよ。

365 名前:デフォルトの名無しさん mailto:sage [2011/06/19(日) 14:17:31.32 ]
わかりました。
勉強してきます!



366 名前:デフォルトの名無しさん mailto:sage [2011/06/19(日) 14:25:48.06 ]
よーし、じゃあ俺も!

367 名前:デフォルトの名無しさん mailto:sage [2011/06/19(日) 14:51:58.33 ]
>>364
お前は日本語を勉強しろよ・・・ それはたとえの部分だろ

368 名前:デフォルトの名無しさん mailto:sage [2011/06/19(日) 15:41:46.66 ]
>>362
そんなことはずっと昔にわかっている・・・というか、
昔は遅延が大きかったので、遅延が発生するのが前提で設計されていた。
それを遅延が無いのを前提で使い倒すようになったのは最近の話。

数時間〜数日単位の遅延が発生する場合でも、Windowsサイズを大きくして、
タイムアウトを長くとれば、それなりにちゃんと動くはず。
もちろん遅延が大きいので、アプリケーションレイヤのプロトコルは
それなりに設計していないと使い物にはならない。

エラー訂正などについては、物理層の仕事。


369 名前:デフォルトの名無しさん [2011/06/19(日) 15:45:51.10 ]
受信済みのデータを削除する方法を教えてください。
今までは空読みしてたんですが、どう考えてもこれって無駄ですよね。
なにかいい方法ありますか?

370 名前:デフォルトの名無しさん mailto:sage [2011/06/19(日) 16:09:16.84 ]
>>367
例えだからと言って、堂々と間違い書いてたら相手にされなくなるぞ。

371 名前:デフォルトの名無しさん mailto:sage [2011/06/19(日) 16:21:02.62 ]
>>368
そういうことを言いたいんじゃないんですよ。

例えば火星で人が病気にかかったとして、
地球に対して、治療方法を聞くとするでしょ。

もし、パケットが不着だと、再送するだけでも40分かかる。
それは、windowサイズやタイムアウトを長くとっても
回避できますか?

エラー訂正が物理層の仕事なら、
なんでTCPに再送制御の仕組みが備わってるんですか?

パケット自体を冗長化するようなアプローチが有っても良いんじゃないんですか?
ってことです。


372 名前:デフォルトの名無しさん mailto:sage [2011/06/19(日) 16:26:50.99 ]
deep space networkでぐぐれ

373 名前:デフォルトの名無しさん mailto:sage [2011/06/19(日) 16:27:34.94 ]
絶対確実に届くUDPがあったらいいなぁっていう鼻血だろ

そんなことも言ってはいけないって言葉狩りじゃまいか

374 名前:デフォルトの名無しさん mailto:sage [2011/06/19(日) 16:32:38.11 ]
>>371
>エラー訂正が物理層の仕事なら、
>なんでTCPに再送制御の仕組みが備わってるんですか?

物理層で訂正できないエラーが発生するから。

>パケット自体を冗長化するようなアプローチが有っても良いんじゃないんですか?

パケットと言うのがどこを指しているのかよくわからんけど、TCP レイヤーの
パケットを言っているなら、そう言うアプローチは無意味だから。

375 名前:デフォルトの名無しさん mailto:sage [2011/06/19(日) 16:34:33.18 ]
>>373
>そんなことも言ってはいけないって言葉狩りじゃまいか

誰も言ってはいけないなんて書いてないと思うが。
ただ相手にされなくなるだけで。



376 名前:デフォルトの名無しさん mailto:sage [2011/06/19(日) 17:03:33.12 ]
>>374
>パケットと言うのがどこを指しているのかよくわからんけど、TCP レイヤーの
>パケットを言っているなら、そう言うアプローチは無意味だから。
なぜ無意味なの?
誰か実験したの?

377 名前:デフォルトの名無しさん mailto:sage [2011/06/19(日) 17:06:24.90 ]
物理的にパケットが届くのに20分かかるなら
なにをどうしても「不着」が発生したら40分のロスは生じる

まずは物理的なレイヤーで、光速を超える通信ができる技術を考えてくれ
それが無理なら、結局は最悪遅延すること前提で設計するしかない

378 名前:デフォルトの名無しさん mailto:sage [2011/06/19(日) 17:11:32.04 ]
>>375
SCTPの説明をするときよくそういう言い方する

379 名前:デフォルトの名無しさん mailto:sage [2011/06/19(日) 17:25:32.70 ]
>>376
物理層と同じ機能を TCP レイヤーで持ってもしょうがないから。

それは間違っているとか、すげーいい方法考えたとか言うなら、
それこそ実験や理論で証明するなりすればいいと思う。

380 名前:デフォルトの名無しさん mailto:sage [2011/06/19(日) 19:39:09.66 ]
>>371
>例えば火星で人が病気にかかったとして、
>地球に対して、治療方法を聞くとするでしょ。

なんでわざわざ地球に聞くの?
火星にいる人に聞けば問題ないのに。
え?火星で解決できなかったからだって?
事前に想定した事態に対する荷物しか用意していないし、
事前に用意した荷物なら使い方を知っているし、
その範囲でどうにかできないなら、同意ようもない。

381 名前:デフォルトの名無しさん mailto:sage [2011/06/19(日) 19:43:26.21 ]
>>371
>もし、パケットが不着だと、再送するだけでも40分かかる。
>それは、windowサイズやタイムアウトを長くとっても
解決できるよ。ちゃんと40分後に再送され、運が良ければ60分後に届く。

>なんでTCPに再送制御の仕組みが備わってるんですか?
物理層以外でデータをロストする可能性があるから。


382 名前:デフォルトの名無しさん mailto:sage [2011/06/19(日) 19:47:04.06 ]
>>371
>パケット自体を冗長化するようなアプローチが有っても良いんじゃないんですか?
あるよ。アプリケーションレベルで好きに実装すればよい。
IP電話なんかは、一部のパケットが無くなっても問題ないようになってるし。

383 名前:デフォルトの名無しさん mailto:sage [2011/06/19(日) 19:47:35.41 ]
>>380
バカが考えた例え話は突っ込みどころ満載だから、バカは例え話しない方が良いぞ。
事前に用意した荷物をどの組み合わせと順序で使えばいいか。

384 名前:デフォルトの名無しさん mailto:sage [2011/06/19(日) 20:03:29.53 ]
>>362
> パケットの送信に何十分もかかる状態なら、
> いっそパケットを多重化してしまえば再送が必要ないんじゃないかなと。

別チャンネルにする必要はなくって、物理層が冗長符合を大量に持って
謬り訂正すればいいだけじゃね?

誰かも書いてたけど再送要求でてもそれが届くのは数十分後

> どちらかというと絶対確実に届くUDPの方が近い気がしてきた。

絶対確実に届かないのがUDP
つか、エラーパケットは積極的に捨ててる実装しかみたことがない


385 名前:デフォルトの名無しさん mailto:sage [2011/06/19(日) 20:07:43.20 ]
>>380
ねえ、ネタでやってるの?
>>371 の例えもどうかと思うが、そんなとこに突っ込みいれる君はそれ以上だよ。

>>382
> IP電話なんかは、一部のパケットが無くなっても問題ないようになってるし。

全然違う話を持ってくるなよ...。



386 名前:デフォルトの名無しさん mailto:sage [2011/06/19(日) 20:08:36.36 ]
>>361
ありがとう。謎が解けた。なんとかなりそう。

387 名前:デフォルトの名無しさん mailto:sage [2011/06/19(日) 21:49:09.41 ]
パケットのじょうちょうか


388 名前:デフォルトの名無しさん mailto:sage [2011/06/19(日) 21:57:18.89 ]
すまん。iPhoneなもんで間違って送信ボタンに当たった。
パケットの並列送信による冗長性確保に付いて言いたい事があるが、また後でな。

389 名前:デフォルトの名無しさん mailto:sage [2011/06/19(日) 22:56:18.77 ]
>>373
> そんなことも言ってはいけないって言葉狩りじゃまいか

そんな考えは無駄だってことを、
Token Ringや100VG AnyLANやATMが教えてくれたんですよ。

390 名前:デフォルトの名無しさん mailto:sage [2011/06/19(日) 23:11:46.30 ]
冗長化よりも行間(パケット間)を読み取る能力が大事と言うことですね

391 名前:デフォルトの名無しさん mailto:sage [2011/06/20(月) 15:12:18.40 ]
気になったけど、ウィンドウサイズ大きいほうがエラーで廃棄される確率高いと思うけどな。

再送に40分かかる距離として、どれだけ冗長に送っておいたほうがスループットいいのかは検証が必要だ。

392 名前:デフォルトの名無しさん mailto:sage [2011/06/20(月) 15:16:24.89 ]
「思う」って言われても…
それは通信路の性質によるし。

帯域は太い、しかしラウンドトリップタイムが大きい通信路で、
転送効率上げるにはウィンドウを大きくするのは定石で、
今のTCPにもヤコビソン先生が衛星回線用に書いたロジックが入ってる。

393 名前:デフォルトの名無しさん mailto:sage [2011/06/20(月) 16:57:30.41 ]
なんのためにLGAMGAHGA三段階にしてあると思ってるんだこいつ

394 名前:デフォルトの名無しさん mailto:sage [2011/06/20(月) 17:51:12.84 ]
じゃあそれぞれのパケットドロップ率を描いてくれよw

395 名前:デフォルトの名無しさん mailto:sage [2011/06/20(月) 18:01:27.02 ]
>>394
T・C・P! T・C・P!



396 名前:デフォルトの名無しさん mailto:sage [2011/06/20(月) 21:47:17.93 ]
>>395
mopera経由の通信モニターしてると結構TCPセグメントが焼失して再送が発生してるわけだが


397 名前:デフォルトの名無しさん mailto:sage [2011/06/20(月) 23:25:34.74 ]
>>396
だったらそのTCPくっつけて見られるようにしてくれよ

398 名前:デフォルトの名無しさん mailto:sage [2011/06/21(火) 00:32:50.51 ]
くだらん話が続いてるな。

399 名前:デフォルトの名無しさん mailto:sage [2011/06/21(火) 05:58:59.22 ]
ドコモのデータ通信程度でも5パケットに一回程度はエラーで再送されてたりするのかな?
家政往復なんて1万個パケット送って1こと独程度だったりしてw

400 名前:デフォルトの名無しさん mailto:sage [2011/06/21(火) 11:29:59.74 ]
それは通信路、通信相手による。
パケットのロスはほとんど輻輳なんだから。
はやぶさなんか専用線なんだから輻輳ロストなんてほぼ0。
通信路の性質上、バーストロストは頻度高いだろうけど。

ただこういうのは、土方プログラマーが考えることじゃない。
最低でもStevens本くらい読みこなしてないと考える意味がない。

401 名前:デフォルトの名無しさん mailto:sage [2011/06/21(火) 11:32:49.07 ]
専用線っていえば、そうなんだろうけど

402 名前:デフォルトの名無しさん mailto:sage [2011/06/22(水) 09:47:59.90 ]
>>400
専用線なんだっけ? あれって他の人は使ってないの?

403 名前:デフォルトの名無しさん mailto:sage [2011/06/22(水) 11:33:42.58 ]
データ受ける側は世界中にいるけどな

404 名前:デフォルトの名無しさん mailto:sage [2011/06/22(水) 21:32:14.30 ]
>>388
>すまん。iPhoneなもんで間違って送信ボタンに当たった。
>パケットの並列送信による冗長性確保に付いて言いたい事があるが、また後でな。
まだ〜?

405 名前:デフォルトの名無しさん mailto:sage [2011/06/23(木) 02:48:07.33 ]
マカってホント情報弱者だな。



406 名前:デフォルトの名無しさん mailto:sage [2011/06/23(木) 08:43:12.98 ]
マカってホント肉体疲労・虚弱体質な人向けネットワークプログラムに向いてるよね。

407 名前:デフォルトの名無しさん mailto:sage [2011/06/23(木) 11:05:34.92 ]
>>402
何を言っているのだ、お前は。

408 名前:デフォルトの名無しさん mailto:sage [2011/06/23(木) 12:35:19.83 ]
>>407
はやぶさとの通信の話だよ

409 名前:デフォルトの名無しさん mailto:sage [2011/06/23(木) 13:34:59.86 ]
はやぶさの近くに同じ周波数帯を使う物体が飛んでいるのか?

410 名前:デフォルトの名無しさん mailto:sage [2011/06/23(木) 13:38:23.97 ]
はやぶさに偽指令って送ることは可能だった?

411 名前:デフォルトの名無しさん mailto:sage [2011/06/23(木) 14:16:46.03 ]
>>410
可能だった。

412 名前:デフォルトの名無しさん mailto:sage [2011/06/23(木) 14:51:23.10 ]
楕円暗号とかの署名付けて送らないと無視するぐらいの機能はついているべきだな。

413 名前:デフォルトの名無しさん mailto:sage [2011/06/23(木) 16:26:03.54 ]
「楕円暗号復号回路が壊れました!署名を検証できません!」
「こんなこともあろうかと、署名無してもコマンドを受けつけるようにしておいたんだ!」

414 名前:デフォルトの名無しさん mailto:sage [2011/06/23(木) 23:09:50.11 ]
>>406 せつこ それ ネットワークビジネスや

415 名前:デフォルトの名無しさん mailto:sage [2011/06/24(金) 00:34:17.50 ]
あまりにも通信状態が悪くて署名で付けた楕円暗号が毎回エラーで、タイミング会わずに軌道に乗れずに宇宙の彼方に飛んでいったってのはあるだろうなw



416 名前:デフォルトの名無しさん mailto:sage [2011/07/02(土) 15:19:04.55 ]
UDP通信でNat越えしたいんですが、
パケット、セッションについて教えてください。

ネットでサンプルプログラムを見ると、クライアント側では
while( true ) {

送信処理(サーバへ)
受信処理(送信処理で使ったsockaddrを使用)
}

こんな感じになっているんですが、このときの送信処理というのは何回も
必要なのでしょうか?

また、発信元ポートというのは、宛先が同じ間でも変わることがあるのでしょうか?

ちなみにNat越えはNat内のクライアントと外部のサーバ間を想定しています。

417 名前:デフォルトの名無しさん mailto:sage [2011/07/02(土) 20:39:00.59 ]
>>416
> こんな感じになっているんですが、このときの送信処理というのは何回も
> 必要なのでしょうか?
NATやってるルーター次第

> また、発信元ポートというのは、宛先が同じ間でも変わることがあるのでしょうか?
バークレイソケットインターフェースだとよほどの変態実装でない限り
socket()で作られた発信元ポートは変化しないと思われる


418 名前:天使 ◆uL5esZLBSE mailto:sage [2011/07/03(日) 12:40:19.28 ]
これ ; デリミタっていうんだけどさ、これをつけなきゃエラーになるような
そんな言語使ってる奴ってどうみてもゴミだと思うんだけど

もしかして「;」これ打ち忘れてコンパイルエラー出すのが楽しいの?
そうか、二度と話かけんなよ
きも

419 名前:デフォルトの名無しさん mailto:sage [2011/07/03(日) 21:45:44.14 ]
(^_^;)

420 名前:デフォルトの名無しさん mailto:sage [2011/07/03(日) 21:58:31.57 ]
デリミタ=区切り文字だから、改行で意味が区切られる言語も対象ってことは・・・
アセンブラか 流石にそこまでローレベル言語は使いたくないな

421 名前:デフォルトの名無しさん mailto:sage [2011/07/03(日) 23:44:05.45 ]
すれ違いのマルチは死ねばいいが
pythonの「:」も存在価値が微妙

422 名前:416 mailto:sage [2011/07/04(月) 00:19:35.96 ]
>>417
ありがとうございます。
とりあえず、送信と受信は別スレッドにして良さそうですよね?

423 名前:デフォルトの名無しさん mailto:sage [2011/07/04(月) 09:18:14.46 ]
Rubyの行継続ルールは微妙

424 名前:デフォルトの名無しさん mailto:sage [2011/07/04(月) 11:08:54.00 ]
rubyはうんこだからしかたない。
というかネットワークには関係ない言語だからスレ違いだろう。

425 名前:416 mailto:sage [2011/07/05(火) 08:29:00.96 ]
416の内容でクライアントがVPNを利用して、
DMZ内にあるサーバと通信する場合だと、
416のやり方でも大丈夫でしょうか?

ちなみにVPNはCiscoのIPsecを使っています。
NAT トラサーバルとか、良くわかりません。。



426 名前:デフォルトの名無しさん mailto:sage [2011/07/05(火) 09:38:52.80 ]
>>425
わからないなら学べ。勉強しろ。

427 名前:デフォルトの名無しさん mailto:sage [2011/07/05(火) 17:22:13.84 ]
vpn糞遅いからな。sslしてるのと変わらない。

428 名前:デフォルトの名無しさん mailto:sage [2011/07/05(火) 19:26:37.46 ]
>>427
根拠は?
IPsec なら専用ハード積んでる GBE だと wire rate でるんだが?



429 名前:デフォルトの名無しさん mailto:sage [2011/07/05(火) 19:32:50.94 ]
大丈夫だ、問題ない。

430 名前:デフォルトの名無しさん mailto:sage [2011/07/06(水) 09:56:55.51 ]
>>428
専用ハードをツンデレ場だろ。 うちのPCはツンデレ場が無いよ

431 名前:416 mailto:sage [2011/07/06(水) 20:09:59.35 ]
VPNですが、サーバまでは通信されましたが、
戻りの通信が出来ませんでした。

クライアント側は3G回線+VPNです。
これって、VPNのASAとかの問題でしょうか?

432 名前:デフォルトの名無しさん mailto:sage [2011/07/06(水) 20:59:42.32 ]
>>431
どこでマミられたかわからないとデバッグできないぞ
ルータでドロップ全部ログる設定にしてやりなおしてみたら?

433 名前:デフォルトの名無しさん mailto:sage [2011/07/06(水) 21:23:18.34 ]
一番いい装備で頼む。

434 名前:416 mailto:sage [2011/07/06(水) 22:57:57.99 ]
>>432
確かにデバッグが必要ですよね。。
本番の環境しかないため、自分の権限では、ここから先は出来ません><
テスト用の環境作るにも機材が必要になるので、厳しそうです。

とりあえず、当初の目的だった、外部サーバとNAT内のクライアントで通信が
出来ればよしとします。。

435 名前:デフォルトの名無しさん mailto:sage [2011/07/07(木) 00:18:48.32 ]
>>434
よかったな。
もしもテスト環境をポンと渡されたらと思うとぞっとするわ



436 名前:デフォルトの名無しさん mailto:sage [2011/07/08(金) 04:57:51.84 ]
>>435
あぁ本当に。
「治るまで作業してていいからね♪」ってサーバー室に閉じ込められた事ならある。
よくよく調べたら、ネットワーク構成図には書かれていないファイアウォール・・・。

使っていたクライアントOSが、何故か毎回同じクライアントポート番号で
接続しに行く不思議仕様だったため、ファイアウォールにたたき落とされていた。


437 名前:デフォルトの名無しさん mailto:sage [2011/07/08(金) 07:28:38.32 ]
セキュリティ嬢どこにファイヤウォールとか入れてるかは明示しないのが普通。
どこで図面漏れるか分からないし。口頭でファイヤウォール入ってないのか確認しなかったのが敗因だな。

むしろなりすましを考慮されてない実装なのが(ry

438 名前:デフォルトの名無しさん mailto:sage [2011/07/09(土) 10:10:33.94 ]
エンジニアリング的におかしいだろ

439 名前:デフォルトの名無しさん mailto:sage [2011/07/09(土) 15:09:03.29 ]
UDPで、一度に大きなサイズのデータ(数十万バイト)は送れないのですが
具体的に、最大どれくらいのサイズまでならば可能なのでしょうか?

440 名前:デフォルトの名無しさん mailto:sage [2011/07/09(土) 15:10:38.66 ]
500〜1500バイトくらい

441 名前:デフォルトの名無しさん mailto:sage [2011/07/09(土) 15:37:20.88 ]
>>439です
>>440thxです
現在winsock で
320×240×23=230400バイトのフレームバッファーを、
1492バイトで分割して、UDPで下記のサイズに分割送信しています
1492×154回
632×1回
受信側で、分割して送られてきたデータを、230400バイトに、再構築するつもりなのですが、
考え方は間違っていないでしょうか?

442 名前:デフォルトの名無しさん mailto:sage [2011/07/09(土) 15:39:43.70 ]
失礼
×320×240×23=230400バイト
○320×240×3=230400バイト

443 名前:デフォルトの名無しさん mailto:sage [2011/07/09(土) 15:45:13.94 ]
>>441
UDPは送った順に届くとは限らないということは理解してるよね?

444 名前:デフォルトの名無しさん mailto:sage [2011/07/09(土) 15:48:28.15 ]
送った順に到着しない
送ったものが届かない

分割して送るなら ヘッダに通番つけといて
上記2点を考慮することになるが…

再送処理とかしだすと、TCPじゃだめなの?って話になる

445 名前:デフォルトの名無しさん mailto:sage [2011/07/09(土) 16:07:55.46 ]
>>441です、お世話になります

>>443
はい、それは理解できています
>>444
TCP/IPの送受信実験はすでに成功しており、UDPによる、送受信の実験がうまくできないので
数週間、チャレンジしていますが、手がかりがなくて模索しています。
>>分割して送るなら ヘッダに通番つけといて
ここら辺のことをお聞きしたいのですが、単純に考えますと
例えばデータ構造を
stract UDP{
unsigned int serial;
char data[1492];
};
このようなことが、考えられると思います
しかし、これでは、UDPなので、所詮投げっぱなしのデータなわけですよね
そこで、通し番号はTCP/IPの3way handshake で送り
その後、UDPでデータを送るというような、アルゴリズムになるのでしょうか?
それから、2230400のデータですが
1492×154回
632×1回
こんな送り方より
1440×160回の方が、単純で再構築もしやすいですね^^;




446 名前:デフォルトの名無しさん mailto:sage [2011/07/09(土) 16:12:27.19 ]
ごめんなさい、また間違えました
×それから、2230400のデータですが
○それから、230400のデータですが
スマソ

447 名前:デフォルトの名無しさん mailto:sage [2011/07/09(土) 16:29:52.14 ]
UDPのデータにそういうふうに番号を付けて、
「何番までのデータは受け取った」とか「何番のデータはまだ来てない」とかそういう返事を受信側から送信側に送り返す
それを見ながら、未着の(たぶん失われたと思われる)データをもう一度送る
返事も失われることがあるので、何秒か返事がなかったら同じものをもう一度送る
「全部受け取った」という返事が来れば終了

448 名前:デフォルトの名無しさん mailto:sage [2011/07/09(土) 16:43:47.79 ]
>>447
ありがとう
実装してみます

449 名前:デフォルトの名無しさん [2011/07/09(土) 17:02:16.53 ]
TCPじゃだめなの?

450 名前:デフォルトの名無しさん mailto:sage [2011/07/09(土) 17:17:30.04 ]
>>449
>>445です
マルチキャストの実験もしてみたいので、TCPではムリポなのでUDPに拘っています^^;

451 名前:デフォルトの名無しさん mailto:sage [2011/07/09(土) 17:55:46.30 ]
マルチキャストで複数(多数)の受信者から違うパケットの再送要求が来たらどうするつもりなんだろう

452 名前:デフォルトの名無しさん mailto:sage [2011/07/09(土) 17:57:48.84 ]
仮にどうにかできたとして
果たしてそれはマルチキャストと言えるのだろうか

453 名前:デフォルトの名無しさん mailto:sage [2011/07/09(土) 18:24:30.11 ]
>>451>>452
>>448です
そうですね、やはりapache の実装のように、子プロセスのインスタンスを生成し
管理するような、システムを構築するべきでしょうね


454 名前:デフォルトの名無しさん mailto:sage [2011/07/10(日) 17:16:36.87 ]
>>452
パソコンサンデー的なものになると思う。
マルチキャストでネトゲのパッチ配布実験とかしてなかったっけ。もちろん実験だけで実用にはならんけど。

455 名前:デフォルトの名無しさん mailto:sage [2011/07/10(日) 18:54:57.63 ]
まずTCPのセッションを複数張って実装してみて、
それで駄目ならUDPとかマルチキャストとか考えるべき。
大抵TCPで何とかなる。動画サイトを見ろ。



456 名前:デフォルトの名無しさん mailto:sage [2011/07/10(日) 18:56:06.09 ]
それから、>>439
確実に知りたければ"Path MTU Discovery"するしかない。
まあ途中に入っているルータが正直に応えるかどうか不明だが。
IPv6の場合はルータの対応が必須だけども。

457 名前:デフォルトの名無しさん mailto:sage [2011/07/10(日) 22:06:00.41 ]
>>456
IPv6でも続々と変なルータやFireWallが増えてきてるので、
PMTUDが通る前提は崩されつつある。嘆かわしいことだ。






[ 続きを読む ] / [ 携帯版 ]

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<234KB

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef