ネットワークプログラミング相談室 Port30 [転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
主にソケットに関しての質疑応答スレッドです。
Programming UNIX Socket FAQ (日本語訳)
http://www.kt.rim.or.jp/~ksk/sock-faq/indexj.html
Winsock Programmer's FAQ (日本語訳)
http://www.kt.rim.or.jp/~ksk/wskfaq-ja/
関連リンクは>>2-10辺り
足りなかったら適当に付け足してね
前スレ
ネットワークプログラミング相談室 Port28
http://toro.2ch.net/test/read.cgi/tech/1334736934/
ネットワークプログラミング相談室 Port29
http://peace.2ch.net/test/read.cgi/tech/1351670708/
関連スレ
ネットワークプログラミング雑談
http://toro.2ch.net/test/read.cgi/tech/1235800707/ グダグダ言ってないで４２４にさっさと答えろよ。タコ >>440
いいですねその強気
一匹狼にはぴったりです えええ、そういう意味なの？ webサーバー＝ｈｔｔｐサーバーってことなの
「WEBサーバー」って、いろんな機能が入ったサーバーの総称かと思っていた。
メールサーバーは「メールができるだけだろう」くらいにはわかっていたが、webサーバー
ってのはメールもhttpもsmtpもできるんだろうと思ってた。 「UDP」だけでどうやってデータを送信すんだ？
This protocol provides a procedure for application programs to send >444
それはだな coapって上司しだいなの。タコな部下でも上司がしっかりしてると
会社は成り立つ。お前らみたいなタコなUDPでも上司がいちいち面倒見てくれるので
ネットワークで一応食っていけるってことさ。W
わかった？
わかったらサッサと俺の質問に答えろ。 えええ、そういう意味なの？ webサーバー＝ｈｔｔｐサーバーってことなの
「WEBサーバー」って、いろんな機能が入ったサーバーの総称かと思っていた。
メールサーバーは「メールができるだけだろう」くらいにはわかっていたが、webサーバー
ってのはメールもhttpもsmtpもできるんだろうと思ってた。 coapってLinuxなんかが動かず、TCPを実装する余裕がないような
もっと小さなデバイスが対象でしょ？ 単機能のセンサーデバイスとか。 >451
実装の問題よりもTCPはオーバーヘッドが大きいので無駄が多いからだろ。 >452
WEBサーバーの次は、掘立て小屋でも立ち上げな。W HTTPサーバを実装するのは結構大変、あっ「WEBサーバー」ていうのかｗ お前ら10年前からだろ。W
俺は始めたのは3日前だものな。で既にお前らを超えてしまった。
なんか聞きたいことある？ ＧＰＳを成立するためには相対背理論（特殊）を使わなければならない事を説明してください UDPってパケットの消失や重複や順序入れ替えが起こり得るって事になってますけど、
小規模な実環境(ハブ数台を間に挟んだPC同士の通信とか)では、どれ位の頻度で
起きるものなのでしょうか？ こんなの見つけた
ttp://stackoverflow.com/questions/9196791/duplicate-udp-packets-how-often-it-happens
>>472
PCからPLC相手の通信をやってて、通信するパケットに採番する訳にもいかない
状況です。
消失は許容するとして、
順序入れ替え→1秒以上前の「古い」パケットと入れ替わる訳でもなさそう
重複→定期的にPC側のポート番号を変更(クローズ→再オープン)
…で逃げれるといいなぁ。 番号ふれない云々からするとMCﾌﾟﾛﾄｺﾙの1Eか？
PLCにもよるけど 同報（受けたところへ投げ返す）をサポートしてなくて、
固定のIPとポートに送り返すしかできない奴があって
クライアント側はbind でポート番号固定するしかないん 予めタイムアウトゼロ秒でrecv()して読み捨てれば重複しても排除出来るか。
>>475
横河のFA-M3です。PLCに送る(PLCの)コマンドに任意の番号とかを付加出来ないん
ですよ(同社の新しめのやつだと付加出来るらしいけど)。
固定のIPとポートって事は無いです(ネットワーク関係はBSD由来だそうで)。 UDPは、自ホスト以外で使わない方がいいと思う。
自ホスト内ならわりと便利だし >>471
あまりにも様々な条件が絡むので誰も答えられないし誰も保証してくれません
送信側、ハブ、受信側のどこでもパケット落ちが発生し得ます
それがIPプロトコルというものです
そもそもEthernetは100%伝送を保証していません >>478
自ホスト内だと、自ホスト内でCPUその他のリソースの奪い合いになり、
結果としてリミッタとして働くのも利点ですね。
>>480
順序が保証されない事を積極的に利用したネットワークスタックがあったら
やだなぁｗ ウインドーズとリナックスで動くCで書くネットワークアプリは
マクロでwinsockとsocketを場合わけするのが普通ですか？
なんで共通じゃないんですか？
２つ覚えないといけないから大変じゃないですか？
上の３つの質問をします。
よろしくお願いします。 >>483
俺は#ifdefで場合分けするけど
BSDソケット関数の範囲で使うなら全然大変じゃないよ select使うのがアホと言ってるやつがアホなんだよなあ
知ったか初心者なんだから黙ってればいいのに
WindowsとLinuxでソースを共通化する必要がある場合で一番簡単なのがselect使う方法
沢山のコネクション扱う場合でもスレッドをうまく使えば非同期使うより効率よく対応できる 大筋では似通ってるけどスレッドもOSの方言がきついな 質問です。
shutdownとcloseについて色々調べていたところ
https://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q13105844663
ここで回答者が（意訳すると）
「socketをcloseせず、shutdownしただけなら、再度セッション張りなおすこともできるよ」
と答えているのですが、いくら調べてもその方法が見つけられません。
やり方が分かる方は、教えていただけると助かります。
（例えば）httpサーバを作る時に、クライアントのshutdown(s, SHUT_WR)をサーバで検知してリクエストの区切りを検知。
返送とshutdown(s, SHUT_RD);でレスポンスの終了位置を検知させる。
なんてことができるといいなぁと考えています。 >>494
TCPなら
socket() -- close()
connect() -- shutdown()
の関係。
shutdownした後にconnectが成功するTCP/IPのプロトコルスタックは見たことないけど。
AF_UNIXとかならうまくいくかもね。 >>494
その回答者がバカなだけ。>>498も同類のバカ。
そもそもcloseとshutdownはそいつらが言っているような関係ではない。 >>494
質問の前半と後半の関係がよくわからんが...
前半は何かいい手があるのかもしれないけどそんなことが必要になったことがないのでよくわからん
> （例えば）httpサーバを作る時に、クライアントのshutdown(s, SHUT_WR) をサーバで検知してリクエストの区切りを検知。
これは普通に read() のバイト数
= 0 で検出できる
> 返送とshutdown(s, SHUT_RD);でレスポンスの終了位置を検知させる。
サーバー側で shutdown(s, SHUT_WR) するか普通に close() すればいいだけ
shutdown(s, SHUT_RD) はあまり使う機会がない 後半で言いたいことは、TCPって基本ストリームで切れ目が無いから
切れ目を（shutdownで）入れたいってことでしょ
普通に改行コードとか使えばいいよ。HTTPならなおのこと >>504
そういう場合はTCP_NODELAYで制御しろよ >>509
TCP_NODELAYが何だか知らないならそういえばいいのにｗ >>510
もしかして、そのフラグ立てたらネットワーク遅延や再送が回避できるとか思ってる？ >>513
どこをどう斜めによむとそういう妄想が出てくるのかな？ >>514
TCPのストリームがくっつく理由を理解できてない馬鹿がいるから >>515
ああ、TCPのPSHの動作をしらないんだｗ >>516
もしかして、そのフラグ立てたらネットワーク遅延や再送が回避できるとか思ってる？ >>517
どこをどう斜めによむとそういう妄想が出てくるのかな？
どうせお前の頭の中じゃ、遅延したらバッファにたまってPSHをつけても
くっつく、この程度のバカ認識なんだろ？ >>518
実装次第だけど、少なくともくっつけてはいけないという意味のフラグでは無い。
で、くっつける実装はよくある 話にならんなｗ
"\r\n"を付けろなんていってるバカ相手だとこんなもんか。 >>521
TCPの実装やソケットの実装触ったこと無い素人だろ？お前
妄想で話するから逃げるしか無くなるんだよ 技術的な要素を何一つ書きもしないで罵倒を繰り返してるクズに言われても、
怒らせて解説を引き出そうとしている中学生にしか見えないわけでｗ TCP_NODELAY、PSHでどう解決するんだ？
>（例えば）httpサーバを作る時に、クライアントのshutdown(s, SHUT_WR)をサーバで検知してリクエストの区切りを検知。
>返送とshutdown(s, SHUT_RD);でレスポンスの終了位置を検知させる。 blocking i/oで常時readかけてれば、PSHで送られたパケットはくっつくことなくreadできるよ。
バークレィ由来のTCP socketはそうなっているはず。
実装的には、mbufなりskbuffなり、受信したパケットのそのものなり複製のチェインで
管理されているので、その通りにまとまらず複数回受信するようになっている。
winsockあたりは知らんから依存しないほうがいいけど、これに頼っている実装も多いよ。 >>525
PSHするならパケットの中身をTLVにでもすればリクエストの区切りなんて簡単に
検知するだろ馬鹿か。もっと単純な方法だってある。
ストリームを読みきったところが次のリクエストの途中かもしれない、という可能性が
一番の問題なのだから、PSHすれば丸ごと解決。 どうでもいいけど、TLVならまずヘッダだけ読んでヘッダの中の長さ分読めば、
別にTCP_NODELAYなんて使わんでもいいんじゃないかい？
元の話を理解してないから適当に言ってるだけだけど。 httpサーバーを その実装で は色々問題ありそうだけど
俺俺プロトコルで http に似た構造の応答になってるという話なら
アリかもしれない >>529
初心者が陥りやすい罠だなｗ
TCPストリームではTLVのヘッダ長分読めるとは限らないだろ。
ヘッダが読めても残りの長さ分読めるとは限らない。 無駄なこと
>（例えば）httpサーバを作る時に、クライアントのshutdown(s, SHUT_WR)をサーバで検知してリクエストの区切りを検知。
>返送とshutdown(s, SHUT_RD);でレスポンスの終了位置を検知させる。
以上 >>524 > 技術的な要素を何一つ書きもしないで罵倒を繰り返してるクズ
命中率の高いブーメランですね HTTPサーバでTCP_NODELAY？
QUICK/HTTP2/UDP的な実装をする話？ >>535
そんなマシな話じゃないよ
>（例えば）httpサーバを作る時に
意図も理解できずにここだけ拾って、HTTPだぁ！\r\nが区切りでなきゃダメだ！って
思考停止してる馬鹿が騒いでいるだけの話ｗ ■ このスレッドは過去ログ倉庫に格納されています
