ネットワークプログラミング相談室 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/ 質問です。
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が区切りでなきゃダメだ！って
思考停止してる馬鹿が騒いでいるだけの話ｗ >>537
でなきゃダメなんて誰も言ってないから・・・ >>539
お前らが一人なのか何人なのか知らんが、
まともに代案を出して俺と技術で議論することすらできなかった時点で
お話にならないんだよ馬鹿がｗ >>540
お前の間違いが余りにも馬鹿すぎて一斉にツッコまれただけ >>540
とりあえず落ち着いて自分のレスを読み返してみろ TCP_NODELAY、PSHでくっつかなくなるとか一番やばいタイプの勘違い
狭い実験内ではそれでうまくいくように見えることもあるだろうが、だからこそヤバイ TCP_NODELAY も PSH もどっちかって言うとタイミングの指示だからねえ
しかも努力目標みたいなものだからそれに頼ったプログラミングとかあり得んわ >>494にはOSの指定が無い。突っ込み所漫才でした。 TCP/IPストリームに実データとして区切りを書き込まずに、
shutdownで1回分の送信の区切りを表現できるといいなぁと思ったんですけどね
（その後にcloseせずに負荷なくセッションを再構築できるっぽい書き込みだったので）
まあ無いってことですね
残念
それにしてもTCP_NODELAY使えはなかなか面白かったです
パケットが綺麗に順序よくrecvでき、割り込みも即座に解決できてる理想的な環境ならいけるかもしれませんね
私は遠慮しておきますが
16KB送信してきたのに対して、2KBでrecvしたりとか
パケットの並び替えが発生して1回のercvで2パケット分以上取得したりとか
問題ありすぎ TCP_NODELAYで1024バイトを２つsendして、そのあとのタイミングで
2048バイトで受信待ちをしたらどうなるか？
2048バイト１回で受信しきる実装はおそらくこの世にありません。
2048バイトでreadしても1024バイトが２回受信できます。
嘘だと思うなら試してみましょう。 TCP_NODELAYで、一発のsendで送ったものが2度以上のrecvに分かれるなんて普通に起こるんだが
ちなXP時代のWinsock
そんなに綺麗にいくんならネットワークプログラミングで苦労しないんだよなあ・・・ >>551
とりあえずWin10でwinsock2で
TCP_NODELAYかけたソケットに5バイトのsendを4回行って
ｒｅｃｖ1024バイトで受け止めたら一発で20バイトとれたぞ
お前がいるのはあの世か？
というか一発でとれなかったらTCPの受信効率悪すぎてヤバイから実験するまでもないことなんだがな・・・ >>551
とりあえず>>517を理解することから始めろ struct sockaddr* を引数にするライブラリを書いているんだけど
どうせみんな struct sockaddr_storage に保存するんだし
もういっそライブラリ内での引数は全部 struct sockaddr_storage* にしてもいいよな
対外的なところだけ struct sockaddr* にするわ 単純にsocketを使ってTCP/lPでクライアントとサーバーで通信するプログラムをLinuxのC言語で作っています。
ただsocketはノンブロッキングに設定しています。
クライアントはconnectを呼んだ後に正常にサーバーと繋がったか知りたくてselectを呼んでいますが、待ち状態からリターンしてきません。
サーバー側はacceptしており、その後に試しにクライアントへデータを送るとselectがリターンしてくるので、確実にsyn ackはクライアントへ返っていると思います。
selectはサーバーからのsyn ackでは待ち状態は解除されないのでしょうか。
やりたいことはconnectではサーバー応答を待たないで即リターンし、コネクションが確立できたかの結果は別途知りたい。
ググるといくつかのサイトでsocketをノンブロッキングに設定して、connectをコールした後にselectで待つサンプルがありました。
それを真似たのですが、サーバー側はconnec待ちの状態で、クライアントがconnectコール後にselectをコールしてもselectはリターンしてこない。
こうすれば出来る、あるいはそんなこと出来ないなどありましたらご教授お願いします。 select呼んでるのに待ちが発生とか
なんかやらかしてる connectがEINPROGRESSになった後、本当にエラーになってるんじゃないか？
selectに回す前にMSG_PEEKでrecvするといいよ。エラーならrecvのエラーで
取得できる。 select(2) 第３引数を NULL でやってたり？ >>570
何言ってるかわからん。きちんと説明できない馬鹿なの？ >>579
横からだけど>>570ってかなり分かりやすいと思うんだけど
とりあえずクライアント側でメッセージの取りこぼしが無いかどうか見直してみたら 横からだけど「パケットをダンプ」が出来ないんだろう >>570さん自演はやめてください。みっともないですよ。 "!"!"!MOHYO!"!"!"2"
1.[[[HUn≒MUL=POSI≠MAHO+Set*HUGE=SAGE=LOGE=NOISIA=0≒1]]]
2-[[[[[[[E=RAT%2^10%SPELAn!%]&!TOWA&!PEG#!NOLNOL8!#!HYAGO!2#]1*2=1]U]S]0]O]!#PAL!
3--->PAGODOL7&!@17,2222734.15&[[[%%RENRAK6,9,99"^10"]#$11.2%}]KAIJ]{
41.2SSS = RALQI2.β{{{RA4,0,238^97,1,$.S.L.E.I.L."Q5352.15Q"JOL"5*3>>>41.3q}}}>1.2<0
.3φTALHOSI"0">>>105.10<1.235<1.2>51≠52===55.632>V="E=0.835"of"1.32","632",0.683,1.end
{ 本当におかしくなったようだ。
>>570程度のことが理解できなくて、悔しいんだろうなあ。 ☆ 日本の、改憲を行いましょう。現在、衆議員と参議院の
両院で、改憲議員が３分の２を超えております。
『憲法改正国民投票法』、でググってみてください。国会の発議は
すでに可能です。平和は勝ち取るものです。お願い致します。☆☆ 諸先輩型、お知恵拝借したく…。
IE11で動かすJavaScriptから、同じPC上のQt5アプリケーションのQlocalServerにメッセージを送りたいのです。
JavaScriptにはどのような実装をすればよいでしょうか？
制限として、Node.jsはインストールできません。それ以外のJavaScriptのライブラリであれば可です。(ただし、HTMLのheadで読み込めるライブラリに限ります。) >>590
590です。
自己解決しました。
IE11上ではJavaScriptのWebsocketは使用できないと思い込んでいたのですが、使用できることに気付き、解決できました。
※IE9互換を強制していたのが原因でした(汗
大変お騒がせしました。 ■ このスレッドは過去ログ倉庫に格納されています
