[過去ﾛｸﾞ] ネットワークプログラミング相談室 Port23 (1001ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
1: 2008/12/28(日)21:07 AAS
主にソケットに関しての質疑応答スレッドです。
Programming UNIX Socket FAQ (日本語訳)
外部ﾘﾝｸ[html]:www.kt.rim.or.jp
Winsock Programmer's FAQ (日本語訳)
外部ﾘﾝｸ:www.kt.rim.or.jp
関連リンクは>>2-10辺り
足りなかったら適当に付け足してね
前スレ
ネットワークプログラミング相談室 Port22
2chｽﾚ:tech
省3
875: 2009/06/19(金)21:11 AAS
>>874
はぁ?データがユーザアプリ層まで来ねぇって言ってんだけど。
それとも手前はライブラリが仕様通りに動かない可能性まで考慮してるっつーのか。
頭めでてー奴だな。
876(1): 2009/06/19(金)21:15 AAS
だからレイヤーをはっきりと(ry
877: 2009/06/19(金)21:34 AAS
linuxでrecv()するのに最初にサイズの4byteを拾ってから次にサイズ分のrecv()を呼んでるですが
こういう呼び方をするとwindowは小さくなってしまうのでしょうか?
878(1): 2009/06/19(金)22:03 AAS
windowとかもっと下のレイヤーだから関係ない
好きな長さで拾っておｋ
879: 2009/06/19(金)22:09 AAS
もっと下つーかTCP/IPの場合1個下か
データに何が入ってようと関係なく
recvで帰ってきた長さのデータを保証するだけ
880: 2009/06/19(金)22:26 AAS
>>878
気にしないで良いみたいで安心しました。
RCVBUFの残りで変化すると想像してます。
別の質問なんですけど、epollでETを指定した場合で立ち下がりにも反応するのでしょうか?
あとEPOLLOUT+EPOLLETで常にトリガが来る様な気がするんですがそういう物でしょうか?
881: 2009/06/19(金)23:14 AAS
linuxなら想像すんじゃなくてソース読めよ
882: 2009/06/19(金)23:21 AAS
linuxだからソース読むより想像した方がいい。
883: 2009/06/20(土)02:44 AAS
>>876
> だからレイヤーをはっきりと(ry
別にライブラリの内側だってバッファがある分だけ
window切ってそれ以外無視するんだから同じ話だけどな。
884(1): 2009/06/20(土)08:55 AAS
linuxのsocketとか、どこの学習用糞ソース使われてるのやらｗｗｗ
ACK無視して速度出ると多めに送ってくる相手も居れば、途中で廃棄されて全然届かないのも有るのがネットの世界。
あとは不正アクセス目的で不正パケット送ってくる香具師も居る。
885(1): 2009/06/20(土)09:41 AAS
通常：受信→送信
超高速：受信１→受信２→送信２ （送信１は受信２に上書きされてしまって消える）
超高速の場合を回避するようにしたいとなるとどうプログラムかけばいいのでしょうか？
ただし、通常と超高速が混在しているものとして
886(1): 2009/06/20(土)10:02 AAS
>>884
> ACK無視して速度出る
どこのアホスタックだそれは。遅くなることはあっても
早くなることはないぞ。
887: 2009/06/20(土)11:11 AAS
ソース読めば一発でわかることを長々と…
888: 2009/06/20(土)11:12 AAS
外部ﾘﾝｸ:tools.ietf.org
windowに収まらないセグメントはRSTでなければACKを返
送して、何れにせよdropすることになってる。
> If an incoming segment is not acceptable, an acknowledgment
> should be sent in reply (unless the RST bit is set, if so drop
> the segment and return):
>
> <SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>
>
> After sending the acknowledgment, drop the unacceptable segment
省8
889(1): 2009/06/20(土)20:20 AAS
>>886
delayed ackならack待たないでしょ。
TCP加速機の類いは、伝送遅延を克服するために、
積極的にackを無視する。
890: 2009/06/20(土)21:45 AAS
>>885
ＵＤＰでは無理
891(1): 2009/06/21(日)08:57 AAS
アクセラとか届いてないのにACK返して自分のバッファでごにょごにょするのとか間のネットに入れられたりするしなあ。
いまやなんでもありだし、そういう場合を想定して実装するべき。
他所は動くのに、こちらのだけうまく動かないと言われて立場が悪くなるだけ。
892: 2009/06/21(日)12:57 AAS
>>891
アホは書き込むな
893: 2009/06/22(月)11:47 AAS
>>889
> delayed ackならack待たないでしょ。
遅延ACKはACK返す回数を減らして間引く話だよ。
Silly Window Syndrome でぐぐったら出てくる。
決してwindowを無視する話じゃない。
894(1): 2009/06/22(月)12:34 AAS
もしかして、ここにいる連中は rfc も読まずに憶測とか腐ったような
解説本から得た知識だけで、えらそなこと書いてるのか？
895: 2009/06/22(月)13:29 AAS
>>894
この辺の話はrfcの何番を読めばいいですか？
896: 2009/06/22(月)13:43 AAS
std5.txt == rfc791.txt IP
std6.txt == rfc768.txt UDP
std7.txt == rfc793.txt TCP
897: 2009/06/22(月)15:14 AAS
これも追加しといて。
外部ﾘﾝｸ:tools.ietf.org
> The TCP Maximum Segment Size and Related Topics
外部ﾘﾝｸ:tools.ietf.org
> Requirements for Internet Hosts -- Communication Layers
外部ﾘﾝｸ:tools.ietf.org
> Requirements for Internet Hosts -- Application and Support
898(1): 2009/06/22(月)15:29 AAS
個人的には Winsock に関する技術文書は良く書かれて
いると思うんだ（後発だからか？）
↓の該当部分は RFC より取っつきやすいと思う。
外部ﾘﾝｸ[html]:www.kt.rim.or.jp
> 3.16 - Nagle アルゴリズムとは何ですか?
> 3.17 - Nagle アルゴリズムをオフにすべきなのはどんなときでしょう?
> 3.18 - TCP の移動ウィンドウとは何ですか?
> 3.19 - お馬鹿なウィンドウ症候群(silly window syndrome)とは何ですか?
> 3.20 - 遅延 ACK アルゴリズムとは何ですか?
899: 2009/06/22(月)16:49 AAS
>>898
winsock に特化した内容が、あたかも汎用性があるみたいな書き方で
書かれてることがあるから、別のプラットフォームに行ったときに
痛い目見たりするけどな…
900: 2009/06/22(月)19:58 AAS
上の rfc をテンプレに入れるべきなのでは？？？
901: 2009/06/22(月)20:12 AAS
winsockほど糞なものは探すのが難しい
902(1): 2009/06/23(火)04:42 AAS
外部ﾘﾝｸ[html]:www.kt.rim.or.jp
このpingのソースなんですけどrecvしたパケットの
IPヘッダのチェックサムもICMPヘッダのチェックサムも計算してないですけど
壊れてる可能性は無いのでしょうか？
903: 2009/06/23(火)05:11 AAS
>>902
普通, check sum 間違ってたらProtocol Stack側が廃棄処分するので
ユーザの手元まで届かない
904(1): 2009/06/23(火)22:19 AAS
WinsockでNAT越えするためのサンプルプログラム等ありましたら教えてください
905: 2009/06/23(火)23:24 AAS
俺も>>904のサンプルプログラム欲しい！めっちゃ欲しい！
906(2): 2009/06/24(水)00:10 AAS
普通に送受信すれば、よっぽどアホなNATじゃないかぎり大丈夫。
907: 2009/06/24(水)01:33 AAS
>>906
何が大丈夫なのですか？
908: 2009/06/24(水)02:07 AAS
そもそも何が大丈夫じゃないと思ってるんだ？
909: 2009/06/24(水)02:24 AAS
>>906
普通に送受信とはなんですか？
910(1): 2009/06/24(水)10:25 AAS
何をしたらどうなって同困ってるんだよ
911: 2009/06/24(水)12:10 AAS
>>910
困っているのはサンプルプログラムが見つからないこと
912(1): 2009/06/24(水)12:17 AAS
いやNAT超えで困ってるなら、そもそもNAT越えられないとやらのプログラムはあるんじゃないの？
913: 2009/06/24(水)13:29 AAS
>>912
あなたは勘違いしています。
914(1): 2009/06/24(水)13:47 AAS
NATの所為で通信できない、というシチュエーションは幾つかあるだろうが
それら全部をひっくるめて「NAT越え」と表現するような奴だから
自分が何をしたいのかすら解ってないかも知れない。
915: 2009/06/24(水)13:53 AAS
>>914
解らずともソースコードを追って学ぶ姿勢なのが私です
916: 2009/06/24(水)13:59 AAS
winsock nat traverseで検索すれば見つかるだろ。中は見てないが。
外部ﾘﾝｸ[aspx]:www.codeproject.com
917(2): 2009/06/24(水)14:05 AAS
次はたぶん「UPnPってどうやるんですか？」だろうな。
918: 2009/06/24(水)15:20 AAS
>>917
それはググればわかりますよ。
919(1): 2009/06/24(水)17:43 AAS
>>917
どうやってやるのか、ってソースコードを見ればわかります。
920(1): 2009/06/24(水)19:44 AAS
>>919
なあ…面白いか？
921: 2009/06/24(水)19:46 AAS
>>920
あなた面白いですね
922(1): 2009/06/25(木)06:20 AAS
むしろNATよりもUPnPで外と通信するほうが大事。
rfcが完全に守られてる訳でもないし。ネットワーク的に革新的な装置のほとんどはrfcにない特殊な通信でパフォーマンス稼いでたりする。
rfcも後追いで、先進的な仕様を盛り込まずに実績重視な所も有るからね。実績出るまではrfcに反映されない闇規格黙認の悪循環。
923: 2009/06/25(木)09:08 AAS
>>922
blogでやれ。
924: 2009/06/25(木)14:24 AAS
つーか雑談スレあるぞ
ネットワークプログラミング雑談
2chｽﾚ:tech
925(1): 2009/06/28(日)17:18 AAS
ちょっと相談なんですけれど、
64キロバイトほどのデータを定期的にEthernetのLAN内のマシン一台にリアルタイムに送信するプログラムを書いているのですが、
発信から到着までどうしても1秒ほどのラグが出てしまうのです。
遅延を100ミリ秒以下に抑えたいのですが(遅延をなるべく小さくしたい)、
こういう場合によく使われるテクニックを教えていただけないでしょうか。
また、遅延が起こる原因として考えられそうなことも教えていただければ幸いです。
926(1): 2009/06/28(日)17:20 AAS
TCPでつないでやってるの？
UDPで投げるようにしてみるとか。
927: 2009/06/28(日)18:56 AAS
リアルタイムは無理だろう。
全部のノードをリアルタイムOSに変更して、スパコンに使われる様な高帯域/低遅延ネットワークのハードを導入するしか。
普通のスイッチングハブなんて経由したら普通に遅延するよ。
2chｽﾚ:tech
OpenMPプログラミング
2chｽﾚ:os
出たよーQNX Realtime Platform！！
2chｽﾚ:os
分散ＯＳ
2chｽﾚ:hard
省1
928: 2009/06/28(日)19:28 AAS
> 発信から到着までどうしても1秒ほどのラグが出てしまうのです。
これは異常。100msは楽勝でクリアできなければおかしい。
ボトルネックになってるところがあるはず。名前解決とか。
929: 2009/06/28(日)19:35 AAS
実際に送受信されてるパケットをキャプチャして、
発信側の処理が遅いのか、受信側の処理が遅いのかを特定すべし。
930: 2009/06/28(日)20:01 AAS
パケ分割して生成とか
931: 2009/06/28(日)20:29 AAS
そもそも隣で1Gbpsでnyしてる様なLANかもだし、何とも言えない。
932: 2009/06/28(日)23:09 AAS
pingうったらＴＴＬはいくつになる？
933: 2009/06/29(月)00:58 AAS
>>925
>>926の言うようにTCPなら、
> 3.16 - Nagle アルゴリズムとは何ですか?
を読め。
934(1): 2009/07/01(水)22:52 AAS
udp上で使えるtelnetのようなプロトコルはありませんか？
tcpは環境の都合で使えません
935: 2009/07/01(水)22:56 AAS
UDP の上に IP をのっけちゃうか、かなぁ
IP over UDP とか、TCP over UDP で検索すると何件かかかるみたいだけど、
お望みの解決に近づけるものがあるかどうかはわからない。
936: 2009/07/01(水)23:02 AAS
udpの時点で使いものに成らないと(ry
tcpが駄目ならudpはもっと無理だと(ry
937: 2009/07/01(水)23:38 AAS
UDPを複数使って、ハンドシェーク
938: 2009/07/01(水)23:45 AAS
どうやら既存のプロトコルとしては無さそうですね
まあぶっちゃけ特定ポート垂れ流しレベルでいいんで・・
939: 2009/07/01(水)23:50 AAS
到達性とかを保証するのがTCPで、
UDPは到達性の保証がないわけで、
垂れ流しじゃTCP相当のものは実現できない。
940: 2009/07/02(木)00:45 AAS
>>934
udpは使えるがtcpは使えないってどういう環境の都合？
941: 2009/07/02(木)00:50 AAS
使用してる環境と要求によるな。
ちょっとくらい取りこぼしてもいいんなら、単純な垂れ流しで十分。
942: 2009/07/02(木)01:37 AAS
UDPは「ちょっとくらい」を保証できない。
全部取りこぼしてもいいなら単純な垂れ流しで十分だが。w
943: 2009/07/02(木)02:55 AAS
UDPって順番の逆転とかあるんだっけ？
それが無いと保証があればちょっとはラクなんだが
944: 2009/07/02(木)03:05 AAS
逆転あるよ。
945: 2009/07/02(木)03:07 AAS
番号振れば問題ないよ
946(1): 2009/07/02(木)06:24 AAS
前から思ってたんだけど TCP over UDP って需要ありそうな気がするんだ。
947: 2009/07/02(木)06:29 AAS
番号振っても届かなきゃなあ。
再送求めて、DoSアタック騒ぎに成るのがヲチ。
何のために？
プロトコル番号を、tcp(6)じゃなくてudp(17)にすればほぼ同じでしょ。
問題はそんな変な事してもまともに使えないってこと。
948(3): 2009/07/02(木)06:34 AAS
>>946
同じ階層にoverってどういうことｗ
949(1): 2009/07/02(木)08:09 AAS
>>948
TCPのペイロードに、UDPヘッダつきのデータ流すんだろ。
950(1): 2009/07/02(木)08:54 AAS
>>948
ほかにもSSHoverHTTPとか言いたいことは分かるけど気分悪いよね。
951: 2009/07/02(木)10:42 AAS
IPをUDPにカプセル化すればそこから先は、ユーザランドで好き勝手に出来る。
以前、IP over UDP over SSH over socksで穴開けていたことがあるが、結構使えた。
952: 2009/07/02(木)12:10 AAS
需要があるから実際 IP over UDP とか TCP over UDP を検索すると
あれこれ出てくるんじゃないか。
953: 2009/07/02(木)12:15 AAS
IP over UDPは作ったことあるな。
954: 2009/07/02(木)14:01 AAS
垂れ流しで作ってみたけど、
IPが振られるまで使えないことが今更問題だとわかった
やっぱシリアルのがいいか・・・
955: 2009/07/02(木)14:44 AAS
IPが振られる？
956: 2009/07/02(木)15:00 AAS
DHCP?
957: 2009/07/03(金)00:53 AAS
>>950
そんな程度のことで気分悪くなるなよ
958: 2009/07/03(金)00:53 AAS
何か変な事をやろうとしてる悪寒。
959: 2009/07/03(金)01:10 AAS
沈黙は金
960: 2009/07/03(金)04:41 AAS
沈黙はtimeout
961: 2009/07/03(金)08:51 AAS
再送も無しか。NATタイマが短気で遮断されてるのかもだが。
962: 2009/07/03(金)16:31 AAS
>>948
UDP は hole punching とかあるじゃん。その上で TCP 通す。
でも確かに IP 通した方が便利だね。デバイスドライバにして
OS から NIC I/F みたいに見えるのがいいと思う。
>>949
逆だ逆。
963(1): 2009/07/03(金)17:35 AAS
UDPで正確にデータ通信する方法を考えてみました。
添削お願いします。
■A→Bへの転送
Aは基本的にBの反応(ACK)を伺いながら通し番号付きデータを
一方的に送りつける。BのACKを待たず一度に送りつける量は、
Bの許容範囲内(ウィンドウ)にする。
もしBから何かの番号のACKが届けば、その番号までのデータは
届いたと判断し、ウィンドウをずらして転送を続行する。
受け取り通知のない番号以降のデータはタイムアウトを取り、
それが過ぎたら通知済の番号直後からデータを再送する。
省7
964: 2009/07/03(金)17:36 AAS
例) Bのウィンドウ8として10個のデータ送る。
A B
|----->| 01
|----->| 02
|----->| 03
|----->| 04
|----->| 05
|<-----| 02 02まで届いたと返事
| | A、ウィンドウ += 2
|----->| 06
省21
965: 2009/07/03(金)17:48 AAS
>>963の
>もしも番号が連続しないことを検出したら連続する時点の
>ACKを返し、Bの再送まで待つ。
これ不要でした。
あと、ウィンドウサイズは双方でデフォルト値を決めておいて、
ACK返送時に一緒に送って変更するとかかな。
966: 2009/07/03(金)18:25 AAS
そこまでやるんなら、TCPでやればいいやん。
967(1): 2009/07/03(金)18:44 AAS
TCPは制御できないからね
968(1): 2009/07/04(土)00:27 AAS
TCP で制御できなくて UDP だと制御できるものって何?
大抵自前でやろうとすると結局 TCP に帰着するか、TCP
が注意深く避けている問題に気付かないかのどっちかだ。
TCP はポッと出てきた訳じゃなくて、何年もの実験と研
究を元にしていることを忘れちゃ駄目だ。もちろんそれ
を越えるものを考えられるなら話は別だけど。
969: 2009/07/04(土)00:34 AAS
>>967
お前よりは良く制御するわ。
970(1): 2009/07/04(土)01:12 AAS
TCPは低速リンクでも高速リンクでもそれなりに動作するように作られている。
状況を限定すれば余計な処理が省略できる。
971(1): 2009/07/04(土)01:28 AAS
TCPは返事が返ってこないとフリーズするじゃん。
972: 2009/07/04(土)01:37 AAS
しない。
973: 2009/07/04(土)01:55 AAS
>>970
当然↓位の考察は出来てるんだよな?
外部ﾘﾝｸ[txt]:www.imasy.or.jp
Stevens が亡くなってもうすぐ十年か…。
974: 2009/07/04(土)02:01 AAS
>>971
いいからRFC読めよアホ
975: 2009/07/04(土)02:39 AAS
ACKが帰ってくるまでの間に何か処理したい場合どうすんの？
スレッドとかなしで。
976: 2009/07/04(土)02:58 AAS
それTCPじゃなくてAPIの使い方の問題じゃん
アホはしねよ
977(2): 2009/07/04(土)17:42 AAS
DOSとかなら諦めろとしかいえないしなあ。
逆に何か処理してる間に、ACK返って来たら取りこぼすだろｗｗｗ
ACK帰ってくるのは待つしか無い。
978(1): 2009/07/04(土)17:51 AAS
だからTCP使わずに自分で制御するしかないんだよ
979: 2009/07/04(土)20:00 AAS
ども。上手くいきました。
>>977
ACK蓄えるぐらいのバッファはあるので問題なしでした。
980: 2009/07/05(日)08:48 AAS
>>977
>>978
いいからお前らアホはRFC読んでから出直してこいって。
馬鹿丸出しだぞ?
981: 2009/07/05(日)10:12 AAS
どのRFCかぐらい教えてやれば？
982(1): 2009/07/05(日)10:47 AAS
[RFC793] Postel, J., Editor, "Transmission Control Protocol,"
STD 7, RFC 793, September 1981.
28年前の基礎技術すらろくに理解できてないのに
それについて語ろうとする奴って何なんだ？
983: 2009/07/05(日)11:18 AAS
>>968
＞TCP で制御できなくて UDP だと制御できるものって何?
ネットワークの混雑を無視して、競合するTCPセッションのリソースを強引に奪うプログラムとか。ロスさせることを前提として20%ぐらいのFECかけて送信するみたいなの。
984: 2009/07/05(日)11:22 AAS
でもほとんどの中継機器はTCPに最適化されちゃってるんだよねぇ
985(1): 2009/07/05(日)11:34 AAS
>>982
> 28年前の基礎技術すらろくに理解できてないのに
> それについて語ろうとする奴って何なんだ？
「データシート(規格書でも、ソースでも、…、可)読めや、ゴルァ！！！」
「難しくて分かりません、取りあえず動かす方法教えてください」
ってのが、最近の流行りらしいからなぁ………
986(1): 2009/07/05(日)11:41 AAS
>>985
昔と今では決まり事の数が違いすぎるだろ・・・
人間が変わったわけじゃない、環境が変わったんだ。
987(1): 2009/07/05(日)12:13 AAS
>>986
それもそうなんだが、それ以前に
読もうとする意志のかけらも見当たらない奴が増えてる
現実もあったりするわけだが…
988: 2009/07/05(日)12:31 AAS
>>987
まぁ、プログラミング自体に夢が見られない時代だからな・・
989: 2009/07/05(日)12:36 AAS
腕があれば一本釣りされるいい時代。
990: 2009/07/05(日)14:24 AAS
腕が無くてもコスト重視で素人が割り当てられてる時代。
勉強する時間がないので正解だけ教えてください的なのは多いね。
応用効かなくてウマく動かなくて困りそうだが。
991: 2009/07/05(日)14:27 AAS
コスト重視にならないような？
992: 2009/07/05(日)14:52 AAS
君達はプログラマ在職中
決して顧客から感謝されたり
歓迎されることなくプログラマを終わるかもしれない
きっと非難とか叱咤ばかりの一生かもしれない
御苦労だと思う
省8
993(2): 2009/07/05(日)14:57 AAS
自衛隊は良いよな。
衣食住無料、しかも給料は高額。
それに比べてプログラマは・・・
鬱で自殺するプログラマより訓練で死ぬ自衛隊の方が遙かに少ない。
994: 2009/07/05(日)15:09 AAS
>>993
そう思うなら自衛隊入れば？
995(1): 2009/07/05(日)15:37 AAS
自衛隊の死者の方が桁違いに多いのを知らないのだろうか・・・
996(1): 2009/07/05(日)15:46 AAS
>>995
それは全員志願ですよ。
997: 2009/07/05(日)15:48 AAS
>>993
だったらさっさと自衛隊に入れよクズ
>>996
自殺者なんてみんな志願だろw
自殺は甘え。
998: 2009/07/05(日)15:49 AAS
↓次ｽﾚよろ
999: 2009/07/06(月)14:20 AAS
.
1000: 小倉優子 ◆YUKOH0W58Q 2009/07/06(月)14:21 AAS
1000ならジュースでも飲むか
1001: １００１ Over 1000 Thread AAS
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.247s*