ネットワークプログラミング相談室 Port30 [転載禁止]©2ch.net

**デフォルトの名無しさん** · 2014/10/31(金) 07:57:16.24

主にソケットに関しての質疑応答スレッドです。

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/

**デフォルトの名無しさん転載ダメ©2ch.net** · 2017/02/18(土) 21:39:19.40

さあ

**471** · 2017/02/18(土) 22:19:45.24

こんなの見つけた
ttp://stackoverflow.com/questions/9196791/duplicate-udp-packets-how-often-it-happens

>>472
PCからPLC相手の通信をやってて、通信するパケットに採番する訳にもいかない
状況です。
消失は許容するとして、
順序入れ替え→1秒以上前の「古い」パケットと入れ替わる訳でもなさそう
重複→定期的にPC側のポート番号を変更(クローズ→再オープン)

…で逃げれるといいなぁ。

**デフォルトの名無しさん転載ダメ©2ch.net** · 2017/02/18(土) 22:29:38.01

後出し、LANなら好きにすれば

**デフォルトの名無しさん** · 2017/02/18(土) 22:55:46.21

番号ふれない云々からするとMCﾌﾟﾛﾄｺﾙの1Eか？
PLCにもよるけど　同報（受けたところへ投げ返す）をサポートしてなくて、
固定のIPとポートに送り返すしかできない奴があって
クライアント側はbind でポート番号固定するしかないん

**471** · 2017/02/18(土) 23:46:49.10

予めタイムアウトゼロ秒でrecv()して読み捨てれば重複しても排除出来るか。

>>475
横河のFA-M3です。PLCに送る(PLCの)コマンドに任意の番号とかを付加出来ないん
ですよ(同社の新しめのやつだと付加出来るらしいけど)。
固定のIPとポートって事は無いです(ネットワーク関係はBSD由来だそうで)。

**デフォルトの名無しさん転載ダメ©2ch.net** · 2017/02/18(土) 23:52:02.74

>>476
ここでやれ

ｼｰｹﾝｻ・PLCﾗﾀﾞｰ総合ｽﾚ 10台目 [無断転載禁止]©2ch.net
http://rio2016.2ch.net/test/read.cgi/denki/1467981285/

**デフォルトの名無しさん** · 2017/02/19(日) 01:17:08.54

UDPは、自ホスト以外で使わない方がいいと思う。
自ホスト内ならわりと便利だし

**デフォルトの名無しさん** · 2017/02/19(日) 02:44:43.42

>>471
あまりにも様々な条件が絡むので誰も答えられないし誰も保証してくれません
送信側、ハブ、受信側のどこでもパケット落ちが発生し得ます
それがIPプロトコルというものです
そもそもEthernetは100%伝送を保証していません

**デフォルトの名無しさん** · 2017/02/19(日) 04:54:42.36

捨てられるのはいいが順序が入れ替わるのは困るなぁ

**471** · 2017/02/19(日) 13:16:31.16

>>478
自ホスト内だと、自ホスト内でCPUその他のリソースの奪い合いになり、
結果としてリミッタとして働くのも利点ですね。

>>480
順序が保証されない事を積極的に利用したネットワークスタックがあったら
やだなぁｗ

**デフォルトの名無しさん転載ダメ©2ch.net** · 2017/02/19(日) 13:27:53.47

いいかげんにうつれ

**デフォルトの名無しさん** · 2017/02/20(月) 08:57:00.26

ウインドーズとリナックスで動くCで書くネットワークアプリは
マクロでwinsockとsocketを場合わけするのが普通ですか？
なんで共通じゃないんですか？
２つ覚えないといけないから大変じゃないですか？
上の３つの質問をします。
よろしくお願いします。

**デフォルトの名無しさん** · 2017/02/20(月) 09:39:37.47

cygwin使えば？

**デフォルトの名無しさん転載ダメ©2ch.net** · 2017/02/20(月) 10:28:44.52

知るかぼけ

**デフォルトの名無しさん** · 2017/02/20(月) 13:28:52.43

>>483
俺は#ifdefで場合分けするけど
BSDソケット関数の範囲で使うなら全然大変じゃないよ

**デフォルトの名無しさん転載ダメ©2ch.net** · 2017/02/20(月) 13:46:53.43

selectするのかアホ

**デフォルトの名無しさん** · 2017/02/20(月) 13:48:15.60

>>487
お前誰に言ってるの？

**デフォルトの名無しさん** · 2017/02/20(月) 13:59:03.21

select使うのがアホと言ってるやつがアホなんだよなあ
知ったか初心者なんだから黙ってればいいのに
WindowsとLinuxでソースを共通化する必要がある場合で一番簡単なのがselect使う方法
沢山のコネクション扱う場合でもスレッドをうまく使えば非同期使うより効率よく対応できる

**デフォルトの名無しさん** · 2017/02/20(月) 14:19:44.98

大筋では似通ってるけどスレッドもOSの方言がきついな

**デフォルトの名無しさん** · 2017/02/20(月) 14:22:11.12

例えばC++ならスレッドの扱い標準化されてるやん

**デフォルトの名無しさん** · 2017/02/20(月) 14:27:39.79

効いてるな

**デフォルトの名無しさん** · 2017/02/20(月) 20:44:10.01

>>476
http://rio2016.2ch.net/test/read.cgi/denki/1467981285/989

**デフォルトの名無しさん** · 2017/05/15(月) 22:34:10.39

質問です。
shutdownとcloseについて色々調べていたところ
https://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q13105844663
ここで回答者が（意訳すると）
「socketをcloseせず、shutdownしただけなら、再度セッション張りなおすこともできるよ」
と答えているのですが、いくら調べてもその方法が見つけられません。

やり方が分かる方は、教えていただけると助かります。

（例えば）httpサーバを作る時に、クライアントのshutdown(s, SHUT_WR)をサーバで検知してリクエストの区切りを検知。
返送とshutdown(s, SHUT_RD);でレスポンスの終了位置を検知させる。
なんてことができるといいなぁと考えています。

**デフォルトの名無しさん** · 2017/05/15(月) 22:57:11.38

TCP/IPを勉強した？

**デフォルトの名無しさん** · 2017/05/15(月) 23:32:39.77

サーバのコードを書き換えればできるけどという話

**デフォルトの名無しさん** · 2017/05/16(火) 11:29:08.72

セッションジャックですねわかります

**デフォルトの名無しさん** · 2017/05/16(火) 12:19:36.91

>>494
TCPなら
socket() -- close()
connect() -- shutdown()
の関係。
shutdownした後にconnectが成功するTCP/IPのプロトコルスタックは見たことないけど。
AF_UNIXとかならうまくいくかもね。

**デフォルトの名無しさん** · 2017/05/16(火) 12:22:42.98

笑

**デフォルトの名無しさん** · 2017/05/16(火) 12:30:56.18

>>494
その回答者がバカなだけ。>>498も同類のバカ。
そもそもcloseとshutdownはそいつらが言っているような関係ではない。

**デフォルトの名無しさん** · 2017/05/16(火) 17:44:46.08

>>500
は？どんな関係だと思ってるの？

**デフォルトの名無しさん** · 2017/05/16(火) 17:49:59.75

ただならぬ関係

**デフォルトの名無しさん** · 2017/05/16(火) 21:07:05.85

>>494
質問の前半と後半の関係がよくわからんが...
前半は何かいい手があるのかもしれないけどそんなことが必要になったことがないのでよくわからん

> （例えば）httpサーバを作る時に、クライアントのshutdown(s, SHUT_WR) をサーバで検知してリクエストの区切りを検知。
これは普通に read() のバイト数
= 0 で検出できる

> 返送とshutdown(s, SHUT_RD);でレスポンスの終了位置を検知させる。
サーバー側で shutdown(s, SHUT_WR) するか普通に close() すればいいだけ
shutdown(s, SHUT_RD) はあまり使う機会がない

**デフォルトの名無しさん** · 2017/05/17(水) 13:08:44.51

後半で言いたいことは、TCPって基本ストリームで切れ目が無いから
切れ目を（shutdownで）入れたいってことでしょ
普通に改行コードとか使えばいいよ。HTTPならなおのこと

**デフォルトの名無しさん** · 2017/05/17(水) 13:19:29.54

アホ

**デフォルトの名無しさん** · 2017/05/17(水) 15:20:55.39

chunko鍋

**デフォルトの名無しさん** · 2017/05/17(水) 15:29:55.67

スレのレベルが相変わらずひどい

**デフォルトの名無しさん** · 2017/05/17(水) 23:37:34.09

>>504
そういう場合はTCP_NODELAYで制御しろよ

**デフォルトの名無しさん** · 2017/05/17(水) 23:51:58.48

>>508
なにも解決しないだろ

**デフォルトの名無しさん** · 2017/05/17(水) 23:57:03.20

>>509
TCP_NODELAYが何だか知らないならそういえばいいのにｗ

**デフォルトの名無しさん** · 2017/05/17(水) 23:58:22.45

解説して

**デフォルトの名無しさん** · 2017/05/18(木) 00:10:51.45

恥ずかしくなったか

**デフォルトの名無しさん** · 2017/05/18(木) 01:13:33.30

>>510
もしかして、そのフラグ立てたらネットワーク遅延や再送が回避できるとか思ってる？

**デフォルトの名無しさん** · 2017/05/18(木) 01:39:20.61

>>513
どこをどう斜めによむとそういう妄想が出てくるのかな？

**デフォルトの名無しさん** · 2017/05/18(木) 07:21:50.23

>>514
TCPのストリームがくっつく理由を理解できてない馬鹿がいるから

**デフォルトの名無しさん** · 2017/05/18(木) 09:46:38.04

>>515
ああ、TCPのPSHの動作をしらないんだｗ

**デフォルトの名無しさん** · 2017/05/18(木) 10:02:58.38

>>516
もしかして、そのフラグ立てたらネットワーク遅延や再送が回避できるとか思ってる？

**デフォルトの名無しさん** · 2017/05/18(木) 10:05:38.98

>>517
どこをどう斜めによむとそういう妄想が出てくるのかな？
どうせお前の頭の中じゃ、遅延したらバッファにたまってPSHをつけても
くっつく、この程度のバカ認識なんだろ？

**デフォルトの名無しさん** · 2017/05/18(木) 10:45:04.86

馬鹿が必死に論点を摩り替えようとして土坪にはまる

**デフォルトの名無しさん** · 2017/05/18(木) 10:45:33.15

>>518
実装次第だけど、少なくともくっつけてはいけないという意味のフラグでは無い。
で、くっつける実装はよくある

**デフォルトの名無しさん** · 2017/05/18(木) 11:01:44.99

話にならんなｗ
"\r\n"を付けろなんていってるバカ相手だとこんなもんか。

**デフォルトの名無しさん** · 2017/05/18(木) 11:14:00.48

>>521
TCPの実装やソケットの実装触ったこと無い素人だろ？お前
妄想で話するから逃げるしか無くなるんだよ

**デフォルトの名無しさん** · 2017/05/18(木) 11:15:21.34

おまえもな

**デフォルトの名無しさん** · 2017/05/18(木) 11:18:52.51

技術的な要素を何一つ書きもしないで罵倒を繰り返してるクズに言われても、
怒らせて解説を引き出そうとしている中学生にしか見えないわけでｗ

**デフォルトの名無しさん** · 2017/05/18(木) 11:35:47.15

TCP_NODELAY、PSHでどう解決するんだ？
>（例えば）httpサーバを作る時に、クライアントのshutdown(s, SHUT_WR)をサーバで検知してリクエストの区切りを検知。
>返送とshutdown(s, SHUT_RD);でレスポンスの終了位置を検知させる。

**デフォルトの名無しさん** · 2017/05/18(木) 11:37:39.55

blocking i/oで常時readかけてれば、PSHで送られたパケットはくっつくことなくreadできるよ。
バークレィ由来のTCP socketはそうなっているはず。
実装的には、mbufなりskbuffなり、受信したパケットのそのものなり複製のチェインで
管理されているので、その通りにまとまらず複数回受信するようになっている。
winsockあたりは知らんから依存しないほうがいいけど、これに頼っている実装も多いよ。

**デフォルトの名無しさん** · 2017/05/18(木) 11:40:24.72

>>525
PSHするならパケットの中身をTLVにでもすればリクエストの区切りなんて簡単に
検知するだろ馬鹿か。もっと単純な方法だってある。
ストリームを読みきったところが次のリクエストの途中かもしれない、という可能性が
一番の問題なのだから、PSHすれば丸ごと解決。

**デフォルトの名無しさん** · 2017/05/18(木) 11:42:48.21

HTTPの仕様書と実装を読んだことあるの？

**デフォルトの名無しさん** · 2017/05/18(木) 11:43:41.17

どうでもいいけど、TLVならまずヘッダだけ読んでヘッダの中の長さ分読めば、
別にTCP_NODELAYなんて使わんでもいいんじゃないかい？
元の話を理解してないから適当に言ってるだけだけど。

**デフォルトの名無しさん** · 2017/05/18(木) 11:45:18.30

httpサーバーを　その実装で　は色々問題ありそうだけど
俺俺プロトコルで http に似た構造の応答になってるという話なら
アリかもしれない

**デフォルトの名無しさん** · 2017/05/18(木) 11:46:41.86

>>529
初心者が陥りやすい罠だなｗ
TCPストリームではTLVのヘッダ長分読めるとは限らないだろ。
ヘッダが読めても残りの長さ分読めるとは限らない。

**デフォルトの名無しさん** · 2017/05/18(木) 11:47:52.60

馬鹿同士仲良くしろよ

**デフォルトの名無しさん** · 2017/05/18(木) 11:49:41.93

無駄なこと
>（例えば）httpサーバを作る時に、クライアントのshutdown(s, SHUT_WR)をサーバで検知してリクエストの区切りを検知。
>返送とshutdown(s, SHUT_RD);でレスポンスの終了位置を検知させる。

以上

**デフォルトの名無しさん** · 2017/05/18(木) 11:51:32.45

>>524 > 技術的な要素を何一つ書きもしないで罵倒を繰り返してるクズ

命中率の高いブーメランですね

**デフォルトの名無しさん** · 2017/05/18(木) 11:56:38.07

HTTPサーバでTCP_NODELAY？
QUICK/HTTP2/UDP的な実装をする話？

**デフォルトの名無しさん** · 2017/05/18(木) 12:00:32.74

>>534
>>532

**デフォルトの名無しさん** · 2017/05/18(木) 12:01:31.14

>>535
そんなマシな話じゃないよ
>（例えば）httpサーバを作る時に
意図も理解できずにここだけ拾って、HTTPだぁ！\r\nが区切りでなきゃダメだ！って
思考停止してる馬鹿が騒いでいるだけの話ｗ

**デフォルトの名無しさん** · 2017/05/18(木) 12:13:36.04

>>537
話が理解できないのな

**デフォルトの名無しさん** · 2017/05/18(木) 12:39:18.53

>>537
でなきゃダメなんて誰も言ってないから・・・

**デフォルトの名無しさん** · 2017/05/18(木) 12:51:07.33

>>539
お前らが一人なのか何人なのか知らんが、
まともに代案を出して俺と技術で議論することすらできなかった時点で
お話にならないんだよ馬鹿がｗ

**デフォルトの名無しさん** · 2017/05/18(木) 12:55:19.23

>>540
お前の間違いが余りにも馬鹿すぎて一斉にツッコまれただけ

**デフォルトの名無しさん** · 2017/05/18(木) 13:09:36.41

>>540
とりあえず落ち着いて自分のレスを読み返してみろ

**デフォルトの名無しさん** · 2017/05/18(木) 14:58:55.81

>>494
ところで、どうしたの？

**デフォルトの名無しさん** · 2017/05/18(木) 15:16:22.61

C4H6

**デフォルトの名無しさん** · 2017/05/18(木) 18:53:08.85

TCP_NODELAY、PSHでくっつかなくなるとか一番やばいタイプの勘違い
狭い実験内ではそれでうまくいくように見えることもあるだろうが、だからこそヤバイ

**デフォルトの名無しさん** · 2017/05/18(木) 21:06:44.73

TCP_NODELAY も PSH もどっちかって言うとタイミングの指示だからねえ
しかも努力目標みたいなものだからそれに頼ったプログラミングとかあり得んわ

**デフォルトの名無しさん** · 2017/05/18(木) 21:11:51.08

>>494にはOSの指定が無い。突っ込み所漫才でした。

**494** · 2017/05/22(月) 22:40:58.34

TCP/IPストリームに実データとして区切りを書き込まずに、
shutdownで1回分の送信の区切りを表現できるといいなぁと思ったんですけどね
（その後にcloseせずに負荷なくセッションを再構築できるっぽい書き込みだったので）

まあ無いってことですね
残念

それにしてもTCP_NODELAY使えはなかなか面白かったです
パケットが綺麗に順序よくrecvでき、割り込みも即座に解決できてる理想的な環境ならいけるかもしれませんね
私は遠慮しておきますが

16KB送信してきたのに対して、2KBでrecvしたりとか
パケットの並び替えが発生して1回のercvで2パケット分以上取得したりとか
問題ありすぎ

**デフォルトの名無しさん** · 2017/05/22(月) 22:54:55.59

お前の質問も以後遠慮するよ

**デフォルトの名無しさん** · 2017/05/23(火) 18:23:04.41

起訴からやりのあせ

**デフォルトの名無しさん** · 2017/05/23(火) 20:03:51.47

TCP_NODELAYで1024バイトを２つsendして、そのあとのタイミングで
2048バイトで受信待ちをしたらどうなるか？

2048バイト１回で受信しきる実装はおそらくこの世にありません。
2048バイトでreadしても1024バイトが２回受信できます。
嘘だと思うなら試してみましょう。

**デフォルトの名無しさん** · 2017/05/23(火) 20:05:53.92

よかったな

**デフォルトの名無しさん** · 2017/05/23(火) 23:51:55.53

TCP_NODELAYで、一発のsendで送ったものが2度以上のrecvに分かれるなんて普通に起こるんだが
ちなXP時代のWinsock

そんなに綺麗にいくんならネットワークプログラミングで苦労しないんだよなあ・・・

**デフォルトの名無しさん** · 2017/05/24(水) 00:09:29.45

>>551
とりあえずWin10でwinsock2で
TCP_NODELAYかけたソケットに5バイトのsendを4回行って
ｒｅｃｖ1024バイトで受け止めたら一発で20バイトとれたぞ

お前がいるのはあの世か？

というか一発でとれなかったらTCPの受信効率悪すぎてヤバイから実験するまでもないことなんだがな・・・

**デフォルトの名無しさん** · 2017/05/24(水) 00:33:12.09

>>551
とりあえず>>517を理解することから始めろ

**デフォルトの名無しさん** · 2017/05/24(水) 10:35:34.16

パケットサイズ意識してる？

**デフォルトの名無しさん** · 2017/05/24(水) 11:45:41.07

SCTPでやるという選択肢は？

**デフォルトの名無しさん** · 2017/05/24(水) 14:04:07.96

ルーターのMTU書き換えてないだけだろうな

**デフォルトの名無しさん** · 2017/05/24(水) 15:33:22.60

オプションの実装で盛り上がる（笑）

**デフォルトの名無しさん** · 2017/05/24(水) 15:44:03.92

但し、意味は無い

**デフォルトの名無しさん** · 2017/05/25(木) 17:47:37.48

OOBと混同してるんじゃね

**デフォルトの名無しさん** · 2017/06/23(金) 10:32:04.01

test

**デフォルトの名無しさん** · 2017/07/30(日) 14:05:52.46

struct sockaddr* を引数にするライブラリを書いているんだけど
どうせみんな struct sockaddr_storage に保存するんだし
もういっそライブラリ内での引数は全部 struct sockaddr_storage* にしてもいいよな
対外的なところだけ struct sockaddr* にするわ

**デフォルトの名無しさん** · 2017/07/30(日) 14:52:39.96

チラシの裏に書いておけよ

**デフォルトの名無しさん** · 2017/07/30(日) 15:31:14.78

だからここに書いた！

**デフォルトの名無しさん** · 2017/08/25(金) 14:34:17.71

ネット障害　国内各地で発生　総務省など情報収集
https://mainichi.jp/articles/20170825/k00/00e/040/278000c

**デフォルトの名無しさん** · 2018/02/03(土) 09:43:16.35

単純にsocketを使ってTCP/lPでクライアントとサーバーで通信するプログラムをLinuxのC言語で作っています。
ただsocketはノンブロッキングに設定しています。
クライアントはconnectを呼んだ後に正常にサーバーと繋がったか知りたくてselectを呼んでいますが、待ち状態からリターンしてきません。
サーバー側はacceptしており、その後に試しにクライアントへデータを送るとselectがリターンしてくるので、確実にsyn ackはクライアントへ返っていると思います。
selectはサーバーからのsyn ackでは待ち状態は解除されないのでしょうか。
やりたいことはconnectではサーバー応答を待たないで即リターンし、コネクションが確立できたかの結果は別途知りたい。
ググるといくつかのサイトでsocketをノンブロッキングに設定して、connectをコールした後にselectで待つサンプルがありました。
それを真似たのですが、サーバー側はconnec待ちの状態で、クライアントがconnectコール後にselectをコールしてもselectはリターンしてこない。
こうすれば出来る、あるいはそんなこと出来ないなどありましたらご教授お願いします。

**デフォルトの名無しさん** · 2018/02/03(土) 09:49:25.96

まずパケットをダンプして見たら

**デフォルトの名無しさん** · 2018/02/03(土) 09:49:30.43

select呼んでるのに待ちが発生とか
なんかやらかしてる

**デフォルトの名無しさん** · 2018/02/03(土) 10:21:23.77

connectがEINPROGRESSになった後、本当にエラーになってるんじゃないか？
selectに回す前にMSG_PEEKでrecvするといいよ。エラーならrecvのエラーで
取得できる。

**デフォルトの名無しさん** · 2018/02/03(土) 10:32:27.09

select(2)　　第３引数を NULL でやってたり？