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
ネットワーク対戦でオセロ，ババ抜きなどできるＣ言語のプログラムを作りたいです。
オライリー以外で何かオススメの本とかサイトはありませんか？
827:デフォルトの名無しさん
08/12/16 21:14:43
ねこでもわかるネットワークでいいんじゃね？
わかりやすいよ
ただしＴＣＰで送信データが分割されて受信される対策について
一切説明してないのが残念な一品です
分かってる人は問題ないんだけどね
俺は一回ＳＥＮＤすると１回のＲＣＶで
全部受信できると勘違いしてたからチンダ
今となってはいい思い出です
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
ありがとうございます。
ピンポン方式なので、
そのデータがかえってこないと次が送信できないので、
１０秒ぐらいかなと思い勝手に決めました。
真の許容待ち時間があるわけではありません。
>>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
どういうリアルタイムだ？
１日以内に届けばよいというリアルタイムもあるぞ（コンビニ売り上げ集計とかな）
どの程度（頻度・量）の通信があるのか？
端末・経路のハードウェアはどの程度の性能か？
とかいう要素で決まってくるものだとおもいなされ
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
それ自爆装置やｗ
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は消える
ヤバイくらい消える
ローカルなネットで２台しか繋がっていないテスト環境でも消える
っつーか取りこぼす
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
状況によりけりだろうな。
ＳＩＮＥＴでもノードによっては遅延がでかいし。
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
それは単に送りすぎなだけだよｗ
通信対戦ゲーム作る時、いろいろな環境で実験したが
時々ごっそり消える（しばらく通じなくなる）が、普段は快適。って結果だったな。
最初ネットで拾ってきたテストコードでやったらごっそり消えまくって、UDPひでえって思ったけど、
単にそのテストコードがデータ送りすぎなだけだった。
912:デフォルトの名無しさん
08/12/26 16:29:43
データ送りすぎもいいけど、それはOSやルータ側が処理しきれないで破棄するっていう問題なのか、それともUDPの仕様（の限界）なのかってことじゃないのか？
極端に言えば「処理できるのは１秒に１パケットだけだからそれ以外は破棄よ」ってこともありえる（例えば同期の問題とかで）。
913:デフォルトの名無しさん
08/12/26 16:33:49
送りすぎってのは一回の送信で沢山送ろうとしてるだけなんでは？
それならバシバシ消えると思う
914:デフォルトの名無しさん
08/12/26 20:55:05
ビジーループみたいなループの中で１００バイトのパケットを送り続けるとかやったんでしょ？
テストコードとしてはやりがちだからね。
でもこれだとポロポロ落ちるんじゃね？
スリープ入れないと。