ネットワークプログラ ..
[2ch|▼Menu]
762:デフォルトの名無しさん
08/11/27 12:19:19
>>761
つまり移植性重視で、パフォーマンスは求めてないんでしょ?
そういうケースならJavaで、というかJavaがいいんじゃないの?

クライアントなら別だが、そういうケースでサーバを書くのなら
C/C++なんかを選ぶ理由が俺には分からない
実際にはスレッド、シグナルハンドリング、排他制御の方法、
等々移植性の無いことだらけで、ソケットAPIだけ限定したところで
何の意味も無いと思うけど
一体どんなプログラムを仮定しているの?

763:デフォルトの名無しさん
08/11/27 12:33:16
馬鹿か?
パフォーマンスの時点で最後までJavaなんてありえねえよ。
移植したけりゃ#ifdefで切り分けろ。
常識だろうが。


764:デフォルトの名無しさん
08/11/27 12:41:26
>>763
主張が揺れまくってて意味わかんないな
パフォーマンスの時点でサーバーサイドJavaがあり得ないと言い切るぐらいなら
winsockでselect()/recv()/send()を選択するのはそれこそおかしいでしょ
現在のJava server VMの性能がどの程度か知って言ってるの?

俺は、C/C++を使うなといっているのではなく、
winsockでのネットワークプログラミングも大体同じだという
主張に反論してるだけなんだけど
IOCPとoverlapped I/Oならプロアクターモデルになるし、全然違うでしょ?

765:デフォルトの名無しさん
08/11/27 13:50:52
んで、結局、Cで組めばいいのかJavaで組めばいいのかどっちなんだよ!
はっきりしてくれ!

766:デフォルトの名無しさん
08/11/27 14:00:36
Erlangに決まってるだろ。いまどき排他制御なんてダサダサなことするかよ

767:デフォルトの名無しさん
08/11/27 15:43:21
ここでいいのか分かりませんが、Unix系のマニュアルで、よく、
・コマンド名(2)
・関数名(3)
のように、(数)のような記述がありますが、これはどういう意味で
しょう?


768:デフォルトの名無しさん
08/11/27 15:50:35
>>767
常識で考えれば、年齢だな
お姉ちゃん(17)
とか


769:デフォルトの名無しさん
08/11/27 15:53:53
セクション
man 使ってないとあまり・・・

770:761
08/11/27 15:58:26
>>764
>主張が揺れまくってて
「自分に反論してくるのは世界に一人だけ」ってタイプ?

>>765
どういう環境でもネットワーク絡みのプログラミングは出来るから
ネットワーク以外の要素で決めれ。

>>767
>ここでいいのか分かりませんが
違うけど、態々別スレで訊き直すほどのもんじゃないから答えちゃうと
man ページの章番号。
1がコマンド、2がシステムコール、3がライブラリ、4がデバイスとか
決まってる。

771:デフォルトの名無しさん
08/11/27 16:53:09
>>767
write ってコマンドあるよね。man write ってやると、システムコールの write(2)じゃなくて
ユーザコマンドの write(1) がでてきてしまう。

システムコール調べたかったら man 2 write とか man -s 2 write とかやる

772:デフォルトの名無しさん
08/11/27 19:39:05
まぁいいじゃんか。JavaでもC++でも
私のためにケンカはやめて

773:デフォルトの名無しさん
08/12/02 23:08:28
おまえらネットワークプログラミングしろよ!

774:デフォルトの名無しさん
08/12/02 23:28:06
一方、774はお姉ちゃん(17) でネットワークプログラミングを楽しんだ

775:デフォルトの名無しさん
08/12/02 23:33:00
しばらく来ないうちにまたJAVAかCかでもめてたのかよ
答えは出てるだろ
C++
これ以外ない!!!!!
JAVAのできることすべてC++でできる
C++でできてもJAVAにできないことはある
ヴァーチャルマシンにしてもそうだ
JAVAはプラットフォームを問わないってうたい文句があるけど
そのJAVAとPCを介している部分の大多数はCもしくはC++で書かれている
中学生の優等生と東大、京大生を比べているようなもの
当然大学生はCとC++
わかったかアホどもw

776:デフォルトの名無しさん
08/12/02 23:42:26
Javaネットワークプログラミング買って来た(・ω・)

ネットワークの知識は多少ある程度だけど、この本はかなり簡単な文章で深く掘り下げて書いてあるNE!!
ネットワークのプログラムとは別に知識もつきそうだよ(・ω・)

777:デフォルトの名無しさん
08/12/03 00:08:21
>>775はたぶんSmalltalkをSmallTalkと書いたりするんだろうな
まあ、頑張れ

778:デフォルトの名無しさん
08/12/03 02:46:36
一方東大生はRubyを使った

779:デフォルトの名無しさん
08/12/03 04:47:28
マジレスすると案があったら作らせるだけ
東大にIT土木はいない

780:デフォルトの名無しさん
08/12/03 22:35:49
東大生が既成の言語なんか使うわけないだろ

781:デフォルトの名無しさん
08/12/04 07:23:59
URLリンク(www.google.co.jp)

782:デフォルトの名無しさん
08/12/04 11:11:17
中学生の優等生 Java / VB / PHP
東大 Ruby
京大 Python
社会人 C/C++


783:デフォルトの名無しさん
08/12/04 12:46:34


   / ̄ ̄\
 /   _ノ  \
 |    ( ●)(●)   
. |     (__人__)       社会人っていったら、自作言語だろ・・ それが一番使いやすいだろ・・
  |     ` ⌒´ノ
.  |         }
.  ヽ        }
   ヽ     ノ        \
   /    く  \        \
   |     \   \         \
    |    |ヽ、二⌒)、          \



784:デフォルトの名無しさん
08/12/04 21:12:49
微妙にスレ違いかもしれませんが、
global IP を持っていて逆引きもできる host が /etc/hosts に FQDN なしで登録されていると、
gethostbyaddr や getaddrinfo で調べたときに、
/etc/hosts が優先されて FQDN が不明なことがあります。
こういう場合に DNS に直に引きにいけば良いと思うのですが、
そのあたりを簡単にやるほうほうはありますが?

785:デフォルトの名無しさん
08/12/04 21:20:01
echo > /etc/hosts

786:デフォルトの名無しさん
08/12/04 22:16:51
: > 785
permission denied: 785

787:デフォルトの名無しさん
08/12/05 01:14:35
>>784
/etc/nsswitch.conf の
hosts: files dns

hosts: dns files
にしてみたり
/etc/host.conf の
order hosts,bind

order bind,hosts
にしてみたりとか

でも逆にしない方が幸せかも

788:デフォルトの名無しさん
08/12/05 02:37:52
>>787
設定を変えれば DNS 優先になりそうですが、
システムの設定を変えられないユーザーもいるので、プログラム側で対処したいなと。

789:デフォルトの名無しさん
08/12/05 09:19:28
OSに頼れないなら自分でDNSクライアント部分を書くしかない希ガス

790:デフォルトの名無しさん
08/12/05 10:13:52
逆にOSの設定で動作変えたいときにこんな強引なことされてると腹立つよな

791:デフォルトの名無しさん
08/12/05 10:48:33
>>788
となると res_query(3) とか自分でDNSのリゾルバ呼ぶことになるかな


792:デフォルトの名無しさん
08/12/05 19:14:59
なにか手抜きな方法がないかと思ったのですが、やはりそれですかねえ。
ちと頑張ってごりごりやってみます。

793:デフォルトの名無しさん
08/12/09 00:57:23
RTPプロトコルを勉強のために
実装してみたいのですがサンプルになりそうなものって
ありますか?

794:デフォルトの名無しさん
08/12/09 01:03:29
勉強のためならサンプルなんか見ずにやれやw

795:デフォルトの名無しさん
08/12/09 15:53:37
この辺から適当に探してみれば?
URLリンク(www.voip-info.org)

796:デフォルトの名無しさん
08/12/09 22:34:08
UDPのパケットのシーケンス制御って
どうしたいいのでしょうか

797:デフォルトの名無しさん
08/12/09 22:53:44
自分でシーケンス番号振って並べ替えりゃ良いだろ
そんくらいも思いつかないようじゃやめとけ

798:デフォルトの名無しさん
08/12/09 23:16:56
>>797
まぁそうなんだけどさ
効率よく並べ替える方法が思いつかん
ちょっと知恵くださいよ年末だし優しくしてくださいよ

799:デフォルトの名無しさん
08/12/09 23:21:11
うぜえよ低脳

800:デフォルトの名無しさん
08/12/10 05:25:07
配列インデックスにすりゃO(1)でそ
並べ替える、って意味わからん

801:デフォルトの名無しさん
08/12/10 05:36:11
>>798
教えてやったんだから俺にお年玉くれ

802:デフォルトの名無しさん
08/12/10 10:16:59
>>798
FIFO でも実装したらどうだ。
それか、漢らしく「シーケンスが狂ったパケットは捨てる」とか。

803:デフォルトの名無しさん
08/12/10 14:15:50
「XX番まで到着したよ」と通知して送りなおしてもらうんですね
わかります

804:デフォルトの名無しさん
08/12/10 14:18:55
TCPでおk

805:デフォルトの名無しさん
08/12/10 14:36:23
いまどきFTPを実装するの面倒だし、HTTPでいいかなって・・・
HTTP/UDPのライブラリとかない?(できればjava)

806:デフォルトの名無しさん
08/12/10 14:40:32
普通にTCPじゃいかんの?

807:デフォルトの名無しさん
08/12/10 14:51:57
ヘンタイですねわかります

808:デフォルトの名無しさん
08/12/10 15:05:31
TCPでいいんだけど、LANとか閉鎖ネットで使ったりとかでTCPの信頼性に依存する必要はないときとか。
動画ファイルとか巨大データ・ファイル・サーバからの転送とか個人で使用とか想定してみて。
HTTPとTCPとIPはレイヤーが違うから差し替えるだけ(プラガブルみたいなの)で出来そうじゃないか?
動画ストリーム用みたいな独自プロトコルを策定するのも分かるけど、そういう閉鎖ネットではプロトコルの機能に関心はなくてデータの入出力とストリームの確保だけできればいいから、結局HTTPでいいよ。

809:デフォルトの名無しさん
08/12/10 15:26:20
HENTAIにはTSUNAMI

URLリンク(tsunami-udp.sourceforge.net)

810:デフォルトの名無しさん
08/12/10 16:06:46
FTPじゃんか。TFTPで暗号機能がプラガブルとかだとみんなハッピーなんだけど、
HTTPやFTPがある層の一つ上にセキュリティ層(アプリ層)を作って、FTP/UDP/SSLとかにすればいいかなって感じはする。
HTTPSとかはHTTP専用に実装してるけど、やっぱ今の仕様策定モデルはMVCとプラガブルでしょ。

811:デフォルトの名無しさん
08/12/10 16:32:19
タグ:MVC,プラガブル

812:デフォルトの名無しさん
08/12/10 23:32:43
HTTP にしといて UDP にしたい理由がわからん

813:デフォルトの名無しさん
08/12/10 23:40:41
HTTP仕様(RFC)は、アプリ(サーバ)として広く普及してるから結構いいかも

814:デフォルトの名無しさん
08/12/11 01:56:29
ルーター通らないんじゃなくてよ

815:デフォルトの名無しさん
08/12/11 03:23:08
HP見るとかなんでもない用途なら、自作するまでもなく普通にHTTP(のサーバ)使うだろ。
といって今はtsunamiみたいに広範囲向けのudpに興味あるわけでもないし。
やっぱudpは、p to p でかつ永遠に連続転送(強制流し込みw)かな。
HTTPは仕様上セッションが保障されてるから一度で転送して終わり。

816:デフォルトの名無しさん
08/12/11 03:34:54
UDPはいちいちconnectしなくていいという利点がある。
ルータ超えしたければ間でTCPに変換すればいいし。

817:デフォルトの名無しさん
08/12/11 16:58:39
C言語で同じインターネット内で他のユーザーと通信するプログラムは作れないですか?
writeコマンドみたいな。

818:デフォルトの名無しさん
08/12/11 17:00:17
>>817
writeでいいじゃん


819:デフォルトの名無しさん
08/12/11 17:00:52
すまん net sendと間違えた


820:デフォルトの名無しさん
08/12/11 17:03:27
>>818
writeだといらない文字まで表示されるので嫌です。
もっと好きな文字を送る方法はないですか?

821:デフォルトの名無しさん
08/12/11 17:05:12
arp

822:デフォルトの名無しさん
08/12/11 17:17:32
>>821
arpをというのを使えばできますか?
参考HPを教えてください

823:デフォルトの名無しさん
08/12/11 18:19:07
tcpにおける送受信で、
1. recv(or read) で一文字ずつ受信する方法
と、
2. recvでMSG_WAITALL を指定する方法
では、どちらがいいのでしょうか?

補足ですが、今作っているシステムでは、
パケットの先頭3バイトに後続データの長さを格納しています。
よって、1の方法でやる場合は、
まず3バイト受信できるまで、1バイトずつ読み込み、
その後、後続データ長分を受信できるまで1バイトずつ読み込むのようにやるつもりです。
(もっといい方法ありますか?)


824:デフォルトの名無しさん
08/12/11 18:20:56
net sendと同じ条件ならメールスロットに書けば

825:デフォルトの名無しさん
08/12/11 18:28:03
>>823
URLリンク(www.linux.or.jp)
>MSG_WAITALL (Linux 2.2 以降)
>このフラグは、要求した量いっぱいのデータが到着するまで、操作を停止 (block) するよう要求する。
>但し、シグナルを受信したり、(中略)した場合には、要求した量よりデータが少なくても返ることがある。

ので、MSG_WAITALLを指定したからといって安心してはいけないかと。

3. recvで必要なバイト数を指定して受信し、実際に受信したバイト数を見て
足りなければ再び recv で不足分のバイト数を指定して受信する方法

が俺のおすすめ

826:デフォルトの名無しさん
08/12/16 20:47:45
ネットワーク対戦でオセロ,ババ抜きなどできるC言語のプログラムを作りたいです。
オライリー以外で何かオススメの本とかサイトはありませんか?

827:デフォルトの名無しさん
08/12/16 21:14:43
ねこでもわかるネットワークでいいんじゃね?
わかりやすいよ

ただしTCPで送信データが分割されて受信される対策について
一切説明してないのが残念な一品です
分かってる人は問題ないんだけどね

俺は一回SENDすると1回のRCVで
全部受信できると勘違いしてたからチンダ
今となってはいい思い出です

828:デフォルトの名無しさん
08/12/16 21:34:40
せめてrecvって書こう

829:デフォルトの名無しさん
08/12/16 23:47:28
ねこはソケットについてあんまり書いてなかったからなあ

830:デフォルトの名無しさん
08/12/17 00:16:47
LAN経由で通信を確立させて、ピンポン方式でデーターを送って応答を返してもらおうと思うのですが、応答が許容待ち時間(10秒)に達したら、データ再送or通信切断どちらのほうが適切なのでしょうか。

831:デフォルトの名無しさん
08/12/17 00:22:58
TCP?UDP?

832:830
08/12/17 00:36:29
>>831
TCPです。
本来ならほんの一瞬でデータが応答がかえるはずなので、
どちらのほうがよいのかなと思いました。

833:デフォルトの名無しさん
08/12/17 00:41:13
おちつけ

834:デフォルトの名無しさん
08/12/17 02:39:08
真の許容待ち時間は何秒なんだ?

835:デフォルトの名無しさん
08/12/17 07:00:27
TCPでデータが届いてなければ再送じゃなくてつなぐ所からやりなおしじゃね?

836:デフォルトの名無しさん
08/12/17 09:21:50
再送はUDPしかありえないっすよ


837:デフォルトの名無しさん
08/12/17 12:04:38
inetdは、標準出力関数を呼び出す毎に、パケットを送ってくれるんでしょうか?
それとも、パケットに詰め込めるだけ詰め込んでから、送るんでしょうか?

838:830
08/12/17 22:05:07
>>834
ありがとうございます。
ピンポン方式なので、
そのデータがかえってこないと次が送信できないので、
10秒ぐらいかなと思い勝手に決めました。
真の許容待ち時間があるわけではありません。

>>835 836
ありがとうございました。
切断がよさそうですね。

839:デフォルトの名無しさん
08/12/18 00:20:19
URLリンク(www13.plala.or.jp)
ここのネットワークゲームのプログラムをもっと丁寧に説明してあるような
本知りませんか?

840:デフォルトの名無しさん
08/12/19 19:29:41
sendでゲーム画面をサーバからクライアントに送信するには
引数をどう指定したらいいんだ

841:デフォルトの名無しさん
08/12/19 20:16:08
送信するデータを指定

842:デフォルトの名無しさん
08/12/19 20:37:46
たいていの場合画面は送らない

843:デフォルトの名無しさん
08/12/19 20:54:39
勘違いかもしれんが,サーバはsendで更新情報をメッセージで送って
受け取ったクライアントはその情報を元に画面を更新する
画面自体は送らないでOK?

844:デフォルトの名無しさん
08/12/19 22:32:39
勘違いじゃなくてスレ違い

845:デフォルトの名無しさん
08/12/20 01:24:56
DNSサーバ扱ってるWebサイトで
UDPパケットが分断されずに遅れる最大サイズが512Byteと書いてあるんですが、
これはUDPを使っている他のプログラムにも適用されることですか?

846:デフォルトの名無しさん
08/12/20 01:43:53
DNSのzoneファイルのサイズを512B以下にしろって話か


847:デフォルトの名無しさん
08/12/20 01:53:16
1つのUDPパケットで運ぶことのできるデータ(「ペイロード(荷物)」という)の長さは、
下位層のIPパケットの長さの制約を受ける。(標準の)IPパケットでは、1回の送信で、
最大では65515bytes(65535bytesから、IPヘッダの最低サイズ20bytesを引いたもの)
までのデータを送信することができる(IPヘッダ・オプションが付くと、さらに小さくなる)。
そのため、1つのUDPパケットで送信することのできる最大ペイロード・サイズは、
65515bytesからUDPヘッダのサイズ(8bytes)を減算した、65507bytesまでとなる。
このため、この「長さ」フィールドの値は、8(データが空の場合)〜65515となる。

なお、下位層でIPフラグメンテーションが行われてIPパケットが分割されて送信されても、
UDPで1度に送信することのできるサイズは影響を受けない。
IPパケットのフラグメンテーション(分割)や再構成(元に戻すこと)は、
IP層のレベルで行われるからである。ただしIPフラグメンテーションが禁止されていると
(IPヘッダ中のDF bitがセットされていたり、ルータがフラグメント・パケットのルーティングを
禁止していたりする場合)、より小さなサイズのUDPパケットしか送信できなくなる。

URLリンク(www.atmarkit.co.jp)
URLリンク(www.atmarkit.co.jp)


848:デフォルトの名無しさん
08/12/20 01:59:24

URLリンク(jprs.jp)
▼DNS サーバの最大数

DNS には、そのプロトコルの仕組み上、応答メッセージが 512byte 以内に収
まる必要があり(*1)、上位の DNS サーバに登録できる NS レコードの数には
制限があります。

(*1) TCP への fallback もありますが、ルートサーバなどの上位の DNS サー
バに TCP の接続が集中すると負荷などが問題となり、UDP で問い合わせ
を行う必要があります。


849:デフォルトの名無しさん
08/12/20 02:21:20
Windows
UDP パケットサイズの最大値の既定値は 1280 バイトです。
UDP パケットのサイズを 512 バイトより大きくする場合、
UDP パケットは UDP ホスト以外のデバイス (ルーターなど)
を経由して送信される必要があり、それらのデバイスの中には
512 バイトを超える UDP パケットをサポートしていないものが
ある点を考慮します。すべてのデバイスおよび可能であれば
そのパスの MTU に対応するように UDP パケットの最大値を設定し、
その最大値に基づいて UDP ホストを構成することをお勧めします。

850:デフォルトの名無しさん
08/12/20 05:37:51
>>843
そう、それであってる。スレ違いでもないし。
たとえばネトゲなんかだと、自キャラの座標を鯖が持っていて、そのキャラからの
一定座標内のキャラクタの情報(座標だったりキャラクタの種類だったり見た目に関する情報だったり)を
クライアントに返却し、クライアントはそれをもとに絵を出すという感じ。
テキストデータと画像データではデータ量に相当の差ができるし、絵を送る場合は鯖の負荷も恐ろしいことになる。

851:デフォルトの名無しさん
08/12/20 05:44:27
いやスレ違いだろ

852:デフォルトの名無しさん
08/12/20 06:22:32
クラサバシステムでどういうデータをクライアントに送るべきかって相談とも取れるからここでもいいんじゃないの

853:デフォルトの名無しさん
08/12/20 09:29:01
板違いじゃボケ
>プログラム・ソフトの使い方は PC 初心者板やソフトウェア板へ。
>ウイルス、ハッキング・クラッキングを求めるような発言は禁止です。
>Javascript は Web 制作板、CGI は Web プログラミング板へ。
>業界談義、愚痴はプログラマ板へどうぞ。
>ゲーム関係の話題はゲーム製作板へどうぞ。
>ネタ、板とは関係の無い話題はご遠慮ください。

854:デフォルトの名無しさん
08/12/20 10:50:01
yahohho- yahhohho-
no-bura yahho-

855:デフォルトの名無しさん
08/12/22 09:32:05
>>852
>クラサバシステムでどういうデータをクライアントに送るべきかって相談
「誰か設計からやって下さい」と同義だぞ、それは。

856:デフォルトの名無しさん
08/12/23 10:42:32
リアルタイム性を求められるネットワークプログラミングでは
TCPを使うべきかUDPを使うべきかどっちが良いのでしょうか

857:デフォルトの名無しさん
08/12/23 10:49:00
どういうリアルタイムだ?
1日以内に届けばよいというリアルタイムもあるぞ(コンビニ売り上げ集計とかな)

どの程度(頻度・量)の通信があるのか?

端末・経路のハードウェアはどの程度の性能か?

とかいう要素で決まってくるものだとおもいなされ

858:デフォルトの名無しさん
08/12/23 10:54:21
>>857
1秒間に300000パケットを転送する程度です。

859:デフォルトの名無しさん
08/12/23 11:01:12
1回の交換に必要なのが 300000パケット で
1秒周期に交換作業を行う ってことかな?

860:デフォルトの名無しさん
08/12/23 11:11:23
通信する距離の問題ももちろんあるけど
1/10秒以内の間隔でデータやりとりするならUDP、それ以上の間隔なら両方作って都合いい方使えって感じ

861:デフォルトの名無しさん
08/12/23 11:14:46
それにしても速度が要求される通信だとテストする環境とかネックだな
LANだとTCPでも速度出るし

862:デフォルトの名無しさん
08/12/23 14:39:24
遅延装置を使え

863:デフォルトの名無しさん
08/12/23 15:52:07
遅延装置って何ですか?

864:デフォルトの名無しさん
08/12/23 16:28:26
奥歯にしこんであるスイッチを噛むんだ

865:デフォルトの名無しさん
08/12/23 16:40:23
それ自爆装置やw

866:デフォルトの名無しさん
08/12/23 16:41:18
あ、かそくそーち!のほうか

867:デフォルトの名無しさん
08/12/23 17:02:20
ワロタ

868:デフォルトの名無しさん
08/12/23 18:24:19
悲しいアホ達でした

869:デフォルトの名無しさん
08/12/23 21:34:05
なんかランドセルみたいな宇宙人?を背負うと
周りの連中が遅くなるって漫画あったんだけど、
なんだっけ?周りの連中からは速くて見えない。

870:デフォルトの名無しさん
08/12/23 23:53:37
子泣きじじいを背負えば遅くなるってのは聞いたことがある。

871:デフォルトの名無しさん
08/12/24 01:22:05
童話のうさぎとかめにでてくるかめは宇宙船だったらしいね
時間が止まってる間に竜宮城で酒池肉林
玉手箱開けて老人になったけどあれは時間が元に戻っただけ


872:デフォルトの名無しさん
08/12/24 01:40:47
なんだその餌は
出直せ



ぱくっ

873:デフォルトの名無しさん
08/12/24 11:35:58
宇宙船で時間旅行したっていう話じゃなかったか

874:デフォルトの名無しさん
08/12/24 22:49:10
なんでウサギとカメの話に竜宮城が出てくるんだ?

875:デフォルトの名無しさん
08/12/24 23:06:16
てきとーなIPとポートにsendして、相手が受信しなかった場合
そのデータはどこに行きますか?

876:デフォルトの名無しさん
08/12/24 23:32:26
消えます。
さらにICMPメッセージが帰ってくることがあります。

877:デフォルトの名無しさん
08/12/25 00:02:31
誰が消して誰がICMPを送ってるんですか?

878:デフォルトの名無しさん
08/12/25 00:24:46
1. ルータやホスト。(TCP/IPの前提)
2. その人。

879:デフォルトの名無しさん
08/12/25 00:32:52
消えるってことは残って誰かの迷惑になるというわけでもないってことでしょうか?

880:デフォルトの名無しさん
08/12/25 00:40:26
相手が受信しなかったときって具体的に何だ?
recv/readしなかったときか? それはTCPが受信してバッファにとりあえず入れとく。


881:デフォルトの名無しさん
08/12/25 00:47:41
>>878
ええ?OSやIPのライブラリ(ソフト)じゃないですか?

882:デフォルトの名無しさん
08/12/25 01:19:33
TCPの場合だとコネクトした状態でsendを行ってrecvを行う前に切断してしまったケースとか
UDPならrecvしなかった場合とかです

883:デフォルトの名無しさん
08/12/25 02:38:32
1のような仕組みはあえて仕込まない限り知らないが、
2はアタック検知したユーザが誰だよてめえと思ってみるということかなぁと。
でも俺ならdigする。んで、80番にアクセスすることはあるけどnmapは滅多にしない

884:デフォルトの名無しさん
08/12/25 03:14:10
sendした以上、相手には届いている。


885:デフォルトの名無しさん
08/12/25 05:07:30
sendしただけでは自分のTCPスタックの中にとどまっているかもしれなくね?

886:デフォルトの名無しさん
08/12/25 20:15:46
バウンスしたら迷惑だろ


887:デフォルトの名無しさん
08/12/25 20:40:46
>>877
NET UNREACH   郵便局(ルータ)の中の人「なんだよこんな番地(ルーティング)存在しねーよ。宛先が存在しません、と…」
HOST UNREACH   郵便配達(エンドルータ)の中の人「このマンションにこんな部屋番号(mac address)存在しねーよ。宛先に届けられません、と…」
PORT UNREACH   家の人(ホスト)「『ひろゆき様へ』って…誰だよそんな奴(port)この家にいねーよ、と…」
PROTOCOL UNREACH ニホンゴワカリマセーン

他にもいろいろあるけどこんな感じ。

888:デフォルトの名無しさん
08/12/25 20:47:11
ローカルIP宛てのパケットを外に出しちゃったら
消えずに迷子になるから迷惑って聞いたんですけど
結局どこに行きますか?


889:デフォルトの名無しさん
08/12/25 20:50:47
冥王星あたり

890:デフォルトの名無しさん
08/12/25 21:17:06
プライベートアドレスでなくても
あて先が突然切断したりしてルートを見失った場合、

パケットは
TTLがなくなるまでたらいまわしにされる?
それとも最も近くにあったルータまで行ってそこで見なかったことにされる?

891:デフォルトの名無しさん
08/12/25 21:25:49
ルータやホストはいつでもパケットを捨てていい。
最大努力配送が期待されているだけ。
これがTCP/IPの基本的な原則。

892:デフォルトの名無しさん
08/12/25 21:52:27
IPパケットが(何かの力によって)勝手に消えて、ネットワークのせいでいつまで経っても自ネット・目的先へ届かないってことはあるけど、
そういう時はTCPは再送信が送信元にいくからいいけど、UDPはICMPで再送の通知がされるの?もしかしてもみ消し?

893:デフォルトの名無しさん
08/12/25 21:55:07
UDPだと、UDPパケットが消滅したとき、ルータが必ずICMPとか何か使って再送してねの再送要求を送信先に必ず送るんでしょうか?
それとも、このパケットがちゃんと届いたかどうかもアプリの方が管理するんですか?

894:デフォルトの名無しさん
08/12/25 21:57:32
UDPは何も言わずに捨ててよい

895:デフォルトの名無しさん
08/12/25 21:58:34
UDPはアプリの方で管理

896:デフォルトの名無しさん
08/12/25 22:04:02
パケットの消失は、基本的にはルータやエンドで処理しきれず捨てられるか、寿命が尽きるかのどちらか。
sendしたパケットが相手に届いてちゃんと受けとればけば、recv使用がしなかろうが、TCPのバッファには残る。


897:デフォルトの名無しさん
08/12/25 22:13:26
最近はファイヤーウォールももみ消すよ。

>>893
ICMPもなくなる可能性があります。
基本的に、パケットがなくしてしまってもいいから、
どんどんネットワークをつないでいくってのがInternetの設計方針。
送信保証はエンドツーエンドでやる。つまりサーバとクライアントの仕事。
なくしていいよってことを認めないと、
PC買ってきて家ですぐにつなげなくなる。
電話みたいにISPのルータでの設定が必要になってしまう。
そういうネットワークはみんな滅亡した。
自分でやるのが面倒なプログラマはTCPを使うべき。
まともな再送機構作るのはかなり難しい。

898:デフォルトの名無しさん
08/12/25 22:26:37
UDPは消える
ヤバイくらい消える
ローカルなネットで2台しか繋がっていないテスト環境でも消える
っつーか取りこぼす

899:デフォルトの名無しさん
08/12/25 22:29:10
そりゃ送りすぎなんじゃないの?

900:デフォルトの名無しさん
08/12/25 22:30:39
でも最近では、バルクデータもUDPで送るようなソフトが出てきてるよな。
SINET等の高速回線ではそのほうがいいらしい。

901:デフォルトの名無しさん
08/12/25 22:33:22
>>900
> SINET等の高速回線ではそのほうがいいらしい。

TCP実装するくらいの実力があればね。

902:デフォルトの名無しさん
08/12/25 22:46:56
URLリンク(d.hatena.ne.jp)

903:デフォルトの名無しさん
08/12/25 23:16:05
みんなクリスマスの夜だというのに饒舌だなぁ。
もういいから彼女の元に戻ってやれよ

904:デフォルトの名無しさん
08/12/25 23:53:05
>>901
imihumei


905:デフォルトの名無しさん
08/12/25 23:55:33
状況によりけりだろうな。
SINETでもノードによっては遅延がでかいし。

906:デフォルトの名無しさん
08/12/26 03:47:52
UDPの方が意図通りに組める

907:デフォルトの名無しさん
08/12/26 05:00:00
新規にブラウザのレンダリングエンジンを作りたいんですけど、
とりあえず何が難しいのか分からない

908:デフォルトの名無しさん
08/12/26 05:15:35
ですよねー


909:デフォルトの名無しさん
08/12/26 06:24:24
彼女いないし


910:デフォルトの名無しさん
08/12/26 09:25:06
>>907
頼もしいな。

911:デフォルトの名無しさん
08/12/26 16:01:10
>>898
それは単に送りすぎなだけだよw

通信対戦ゲーム作る時、いろいろな環境で実験したが
時々ごっそり消える(しばらく通じなくなる)が、普段は快適。って結果だったな。

最初ネットで拾ってきたテストコードでやったらごっそり消えまくって、UDPひでえって思ったけど、
単にそのテストコードがデータ送りすぎなだけだった。


912:デフォルトの名無しさん
08/12/26 16:29:43
データ送りすぎもいいけど、それはOSやルータ側が処理しきれないで破棄するっていう問題なのか、それともUDPの仕様(の限界)なのかってことじゃないのか?
極端に言えば「処理できるのは1秒に1パケットだけだからそれ以外は破棄よ」ってこともありえる(例えば同期の問題とかで)。

913:デフォルトの名無しさん
08/12/26 16:33:49
送りすぎってのは一回の送信で沢山送ろうとしてるだけなんでは?
それならバシバシ消えると思う

914:デフォルトの名無しさん
08/12/26 20:55:05
ビジーループみたいなループの中で100バイトのパケットを送り続けるとかやったんでしょ?
テストコードとしてはやりがちだからね。
でもこれだとポロポロ落ちるんじゃね?
スリープ入れないと。




最新レス表示
スレッドの検索
類似スレ一覧
話題のニュース
おまかせリスト
▼オプションを表示
暇つぶし2ch

4758日前に更新/232 KB
担当:undef