ネットワークプログラミング相談室 Port29
レス数が900を超えています。1000を超えると表示できなくなるよ。
0001デフォルトの名無しさん
2012/10/31(水) 17:05:08.29Programming 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/
関連スレ
ネットワークプログラミング雑談
http://toro.2ch.net/test/read.cgi/tech/1235800707/
0840デフォルトの名無しさん
2014/06/19(木) 01:24:12.03ID:AKnufCCZお前>>822か。 いい加減しつこいな。
0841デフォルトの名無しさん
2014/06/19(木) 07:35:31.24ID:ryr/zveK0842デフォルトの名無しさん
2014/06/19(木) 09:04:54.78ID:T3v2xG5Yあらゆる可能性を想定出来ない奴がプログラミングとか趣味でやるだけにしとけ
0843デフォルトの名無しさん
2014/06/19(木) 09:22:39.74ID:WpG/iKEP仕様も知らん奴は趣味でプログラムするだけにしとけ
0844デフォルトの名無しさん
2014/06/19(木) 09:40:15.71ID:pZASkYhqstruct pkt {
int32_t size;
char data[*];
};
こんなパケットの先頭のsizeを読むときも
if (read(s, &size, sizeof(size)) != sizeof(size))
error();
としないのか、大変だな。頑張ってくれ。
0845デフォルトの名無しさん
2014/06/19(木) 10:08:45.11ID:T3v2xG5Yえ
>>844
発現しにくいバグ生むだろそれ
0846デフォルトの名無しさん
2014/06/19(木) 10:47:52.19ID:pZASkYhq> 発現しにくいバグ生むだろそれ
意味不明
0847デフォルトの名無しさん
2014/06/19(木) 10:51:52.22ID:T3v2xG5Y0848デフォルトの名無しさん
2014/06/19(木) 10:54:39.08ID:D9TTjhOo理解できるようになるまで勉強しろ
0849デフォルトの名無しさん
2014/06/19(木) 13:37:52.71ID:iC2KP732仕様です。
って一言が、これほど上手く使えるとは。
0850デフォルトの名無しさん
2014/06/19(木) 13:54:43.05ID:T3v2xG5Yおいｗ
0851デフォルトの名無しさん
2014/06/19(木) 18:46:15.77ID:BRW9+QBS＞あらゆる可能性を想定出来ない
「想定外です」霧
0852デフォルトの名無しさん
2014/06/19(木) 18:48:43.70ID:mP63aYGC4バイト来ることを想定しちゃいかんって事かな?
あと、バイトオーダーも無視してるし
0853835
2014/06/19(木) 20:24:00.87ID:oi99l3rA学校の演習課題で書くプログラムや個人の趣味プロジェクトであれば、
そのコードでもかまわないと思う
あるいは社会人であっても、研究職で研究対象としてのプログラミングなら許される
ただし、24時間365日の連続稼働という設計品質を要求される開発の最前線であれば、
コード設計の実装バグとしてレビューで指摘される
想像してみよう、銀行間で数十万件の取引レコードを転送している時、
偶然にもsizeの途中でデータが途切れてエラーとなったので
転送ジョブが異常終了してしまった
さて、この障害連絡に対して>>844はどう返答する？
「sizeの途中で途切れるなんて予測の想定外でした、私は間違っていません」
などと国会答弁の政治家のような言い訳をするのだろうね、たぶん
では「じゃあ、どうやって実装するのよ？」という想定質問について、
解決策は状況に応じていくつか考えられるけど、
最も汎用的なステートマシンを使う方法を過去スレPort24の類似質問に対して
疑似コード付きでレスしているので、まずはそちらを一読してもらいたい
http://pc12.2ch.net/test/read.cgi/tech/1246895188/931-968
この過去スレの#318が自分のカキコになる
0854デフォルトの名無しさん
2014/06/19(木) 20:25:55.76ID:qy6t50nu0855デフォルトの名無しさん
2014/06/19(木) 20:44:46.89ID:mP63aYGC今時は、全銀手順の手組なんてしないしw
ライブラリー使いましょ。
>>854
ネットワークスレなんだからオクテット足が釣れたと言いましょ
0856デフォルトの名無しさん
2014/06/19(木) 20:47:19.72ID:qy6t50nu銀行で徹夜したことについて謝罪と賠償を請求する
0857デフォルトの名無しさん
2014/06/19(木) 21:30:03.44ID:lQ+uiTbF日本は銀行間取引はRTGSで日銀経由でしている事を
知らない部外者だよ
0858デフォルトの名無しさん
2014/06/19(木) 21:50:09.29ID:Oxl/97Kx0859デフォルトの名無しさん
2014/06/20(金) 00:17:58.19ID:ZdNYCSgz0860デフォルトの名無しさん
2014/06/20(金) 06:36:54.81ID:JSi28Lkjますます意味不明
ネットワークプログラミング相談室 Port24
http://pc12.2ch.net/test/read.cgi/tech/1246895188/931-968の#318
> 318 ： デフォルトの名無しさん[sage] 投稿日：2009/08/12(水) 17:18:44
> >>315
> あー、そうか
> ローカルポートの情報も持ってないとだめですね
318で検索しても他にはないしなあ
0861デフォルトの名無しさん
2014/06/20(金) 07:14:16.63ID:kSpxa/vAhttp://pc12.2ch.net/test/read.cgi/tech/1246895188/950-952
だろう
正直こんなくどいことせず１バイトずつ読めばいいと思うが、
レスもなんかくどいし、まあそういう人なんだろう
0862デフォルトの名無しさん
2014/06/20(金) 07:33:26.53ID:JSi28Lkj> さて、この障害連絡に対して>>844はどう返答する？
error();
の中で処理する。
>>861
#318ではなく#938の可能性微レ存だが、銀行間の数十万件の取引レコードを
処理するプログラムを書く御仁がこんな単純な間違いをしたと、決めつける
のは良くない。本人の釈明を待つことにする。
0863835
2014/06/20(金) 09:20:27.39ID:fiYVjyLm指摘ありがとう、レス#の間違いに気が付けなかった....
X: この過去スレの#318が自分のカキコになる
O: この過去スレの#938が自分のカキコになる
具体的な疑似コードは、過去レス(>>853)の #947 と #950-952
0864デフォルトの名無しさん
2014/06/20(金) 10:59:08.88ID:JSi28Lkjプログラムがここで寝ている時に通信障害の連絡やってきた。
さて、>>853はどう対処する?
銀行間の数十万件の取引レコードの転送の場合は当然
switch (tlv.type) {
default:
error();
brreak;
}
なんて事はしないんだよな。 w
0865デフォルトの名無しさん
2014/06/20(金) 11:05:28.51ID:JSi28Lkj> 質問の意図に沿って「非同期I/Oを前提(だよね？)」とした場合、最も外側のTLV構造の処理は、
> ステートマシン(状態管理処理)と一体になる。疑似コードだと、こんな感じ。
こっちの場合も
while (buf.size() > 0)
buf.size() == 0で抜けてしまうんだが、
while (buf.size() > 0) {
}
if (state != STATE_COMPLETE)
error();
なんて事はしないんだよな。銀行間の数十万件の取引レコードの転送の場合は ｗ
0866835
2014/06/20(金) 11:57:20.19ID:fiYVjyLm「寝ている」とはプロセスがブロック(or スレッド)された状態を意味するのかな？
もしそうなら、過去スレ#950の冒頭で述べているように：
・マルチスレッド構成でTCPコネクション単位に
スレッド処理する設計ならば、ブロックには何の問題も無い
新たに受信データ断片が到着すればスレッドのブロックが解除され、
次のtype別処理を再開できるのだから
・シングルスレッド構成でイベント駆動処理を前提に設計しているのならば、
過去スレ#947の疑似コードは不適切だから
代わりに#950の疑似コードを使えばいい
>>865
バッファが空である(buf.size() == 0)ならば
現時点で到着していた受信データ断片の処理は終わったのだから、
ステートマシンの状態を保持したまま
すみやかにコールバック関数をリターンし、
次の受信イベント発生を待ちうけるべき
こんなのはイベント駆動プログラミングの基本だけど、
>>865はどんなエラー処理を期待しているのかな？
0867デフォルトの名無しさん
2014/06/20(金) 12:21:42.37ID:JSi28Lkj0868デフォルトの名無しさん
2014/06/20(金) 12:58:00.74ID:ZdNYCSgz途中でエラーになるんだから
安全を取って、その電文はエラーログに落として破棄、
ランプ光らせつつ再送に期待じゃない？
0869デフォルトの名無しさん
2014/06/20(金) 13:01:45.74ID:FGk8LmcM0870デフォルトの名無しさん
2014/06/20(金) 13:06:50.29ID:5fUr2YwOselectとnon blocking I/Oを使うんだぞ
それから実装はどうであれSOCK_STREAMのsocketからreadしたとき
何バイト読めるかは保証されていないぞ
0871835
2014/06/20(金) 13:42:16.97ID:fiYVjyLm言われた事しかできません、という「ゆとり世代」かな？
しかたないから、面倒だけど疑似コードから実装コードへ落とし込む方法を
手取り足取り教えてあげよう
（実際に、要領の悪い新人さんを指導しているような気分になりつつあるw）
・イベント駆動を前提にした疑似コード#950であれば、
OSやフレームワークからコールバックされた直後に
readやreceiveシステムコールを発行してソケットから受信バッファに読み込み、
それから#950の状態遷移関数 recv_acceptor をコールする
（状態遷移関数内ではメモリ上のバッファだけを処理するから通信障害は無視できる）
また、通信障害発生の判定はシステムコール発行直後の一ヶ所に限定できるから、
その部分で適切に通信障害発生時のエラー対応処理を実装する
・スレッドのブロックを前提にした同期プログラミングの疑似コード#947では、
TLVリーダのget操作の中のシステムコール発行時に通信障害発生を判定する
ただし、get操作がコードの複数箇所に拡散してしまうから、
例外を投げるとかC言語ならlongjmpで大域脱出するとかして一ヶ所にまとめ、
その部分で適切に通信障害発生時のエラー対応処理を実装する
（もちろんget操作がエラーリターンするよう変更してもいいけど、可読性は落ちる）
0872デフォルトの名無しさん
2014/06/20(金) 13:46:29.95ID:UaHzai/N0873デフォルトの名無しさん
2014/06/20(金) 13:48:20.34ID:+KfxKSN30874835
2014/06/20(金) 13:51:26.94ID:fiYVjyLmそのとおりで、TCP通信がバイト・ストリームであることを理解していれば、
保証されないことは当たり前なんだけど、それを保証するコード設計なんて
面倒くさくてやってられない、というのが>>844君の主張
>>844のコードだと、保証処理を放棄して、通信エラーとして扱うつもりでいる
0875デフォルトの名無しさん
2014/06/20(金) 14:02:40.97ID:JSi28Lkj> その部分で適切に通信障害発生時のエラー対応処理を実装する
銀行間の数十万件の取引レコードの転送の場合は、通信障害でTCPの切断が起こっ
た事と通信終了でreadが0を返した事を判別できるのか?
それはビックリだよ。ｗ
0876835
2014/06/20(金) 14:56:31.68ID:fiYVjyLmまだ続けたいの？
しかたないね、新人教育を続けよう
・ここで扱っている受信メッセージ組立て処理の場合、
メッセージ組み立て中の状態でreadが0を返せば、
それは通信障害によるコネクション切断と判断する
それ以外の状態、すなわち連続するメッセージ間で
readが0を返した場合には判別できないから、
単純に上位へコネクション切断を通知する
・上位のトランザクション処理ではトランザクション処理中に
コネクション切断が通知されたなら通信障害と判断する
ここで、トランザクションとは、たとえばHTTPサーバなら
リクエスト受信開始からレスポンス送信完了までの期間を、
SMTPであればHELLOコマンド受信開始からQUITコマンドに対する
応答送信完了までの期間を指す
それ以外の状態、すなわち連続するトランザクション間で
コネクション切断が通知されたなら正常な通信終了と判断する
ビックリって、何を驚いているのかな？
もしかすると、こういった判定も面倒だからという理由で設計していなかったのね
まあ確かに、一般にネットワークプログラミングはエラー処理のかたまりだから、
慣れない素人さんや学生さんが最初にとまどってしまうのは無理もないのかな
0877デフォルトの名無しさん
2014/06/20(金) 15:01:21.09ID:JSi28Lkj> それは通信障害によるコネクション切断と判断する
後出し仕様 ｗｗｗｗ
> また、通信障害発生の判定はシステムコール発行直後の一ヶ所に限定できるから、
> その部分で適切に通信障害発生時のエラー対応処理を実装する
下位レイヤーが上位レイヤーの状態を知ってるんですかあ? 銀行間の数十万件の取引レコードの転送の場合は。ｗｗｗｗ
0878835
2014/06/20(金) 16:00:42.03ID:fiYVjyLm> 後出し仕様 ｗｗｗｗ
もともと過去レスの疑似コードでは、
readシステムコールを発行する詳細コードを抽象化し、
TLVリーダやバッファといった用語を書いている
そして、その実装は各自で考えてもらえばいいと思っていたけど、
ID:JSi28Lkj君が「僕には実装方法が分かりません」と言い出したから
丁寧に教えてあげているだけだよ
> 下位レイヤーが上位レイヤーの状態を知ってるんですかあ?
知らないから、下位の受信メッセージ組立て処理では
「単純に上位へコネクション切断を通知」して
上位のトランザクション処理に判別を委ねると、
>>876で述べている
もう少し冷静になって文章を読んだほうがいいと思うよ
こちらでは技術関連は指導できても、日本語の読解能力までは面倒みれないから
0879デフォルトの名無しさん
2014/06/20(金) 16:10:48.55ID:ix5aqk/e0880デフォルトの名無しさん
2014/06/20(金) 17:15:41.46ID:fmtXRHPg通信障害は-1が返ってくるし
0881デフォルトの名無しさん
2014/06/20(金) 17:37:38.06ID:qd8xX9Tw> TCP通信がバイト・ストリームであることを理解していれば、
> 保証されないことは当たり前なんだけど
このスレの住人なら、例外を除いてそんなの常識だし、君が力説してるようなことも常識。
それを上から目線で、さもお前らが知らないことを教えてやろう的なレスするから嫌われる。
0882デフォルトの名無しさん
2014/06/20(金) 17:40:23.44ID:JSi28Lkj> 知らないから、下位の受信メッセージ組立て処理では
>>876には
>・ここで扱っている受信メッセージ組立て処理の場合、
> メッセージ組み立て中の状態でreadが0を返せば、
> それは通信障害によるコネクション切断と判断する
下位レイヤーが、上位レイヤーがメッセージ組み立て中の状態である事を知ってるっ
て書いてありますが。ｗｗｗ
0883デフォルトの名無しさん
2014/06/20(金) 17:48:20.00ID:JSi28Lkjメッセージ境界が保存されないTCPでも
write(s, &v, sizeof(int));で書かれたvは
read(s, &v, sizeof(int));で読める。全然問題ない。
問題あると騒いでるバカはすべてのプログラムのreadをと書き換えろ。
(sがソケットになる可能性が0ではないから)
int nread(int s,char *buf, size_t sz)
{
int cc, l;
for (l = 0; l < sz; l += cc)
if ((cc = read(s, buf + l, sz - l)) < 1)
return 0;
return l;
}
0884835
2014/06/20(金) 18:28:03.97ID:fiYVjyLmいや、通信障害という業界用語は、データリンク・レベルのエラー(回線障害)から
アプリケーション間プロトコルのエラーまで、幅広いエラーを含んでいる
そして>>876で書いたように、システムコールが正常終了しても
通信サービスとしてはエラーとして扱うケースもあるから、
read/recvのリターン値 -1 だけでは、すべての通信障害を検出できない
>>881
わかった、では自分は落ちるから、後の >>883(ID: JSi28Lkj)の世話、よろしくたのむ
>>882
君への最後のレスを返す
受信メッセージ組立て処理(下位)とトランザクション処理(上位)という
２個のモジュールがあるという構成を理解できていないのかな？
これ以上は面倒だし、後の世話は>>881にまかせたので、説明は止めとく
0885デフォルトの名無しさん
2014/06/20(金) 18:52:29.32ID:fmtXRHPgブロッキングI/Oだと無限にループから抜け出せない可能性があるし
ノンブロッキングI/Oだとデータ受信が間に合わないときにエラーが
返ってくるので0復帰してしまう
100点満点中10点だな
0886デフォルトの名無しさん
2014/06/20(金) 20:05:21.58ID:JSi28Lkj> 受信メッセージ組立て処理(下位)とトランザクション処理(上位)という
> ２個のモジュールがあるという構成を理解できていないのかな？
> これ以上は面倒だし、後の世話は>>881にまかせたので、説明は止めとく
ぷぷぷっ また後付け。
> また、通信障害発生の判定はシステムコール発行直後の一ヶ所に限定できるから、
> その部分で適切に通信障害発生時のエラー対応処理を実装する
システムコール発行直後でエラー処理を行うとはっきり書いてあるわけだが。
>>885
最後だと言っときながら、余計な事書いて恥の上塗り。みっともないねえ。
> ブロッキングI/Oだと無限にループから抜け出せない可能性があるし
ねーよ。バカ。ｗｗｗ
> ノンブロッキングI/Oだとデータ受信が間に合わないときにエラーが
バカには分からないらしいが、ブロッキングI/Oで書いてあるのは一目瞭然。ｗｗｗ
0887デフォルトの名無しさん
2014/06/20(金) 20:12:22.25ID:fmtXRHPgブロッキングI/Oでreadすると、通信遮断で返ってこなくなるよ
経験のなさがもろに出てるね
0888デフォルトの名無しさん
2014/06/20(金) 20:15:02.16ID:5fUr2YwOとか言ってみる
0889デフォルトの名無しさん
2014/06/20(金) 20:19:43.47ID:JSi28Lkj> 通信障害は-1が返ってくるし
はい、ダウト。 ｗｗｗ
TCPの切断では-1は返ってこない。このバカこの程度の知識で偉そうにしてて大爆笑だわ。
0890デフォルトの名無しさん
2014/06/20(金) 20:20:15.90ID:nPXPLHY10891デフォルトの名無しさん
2014/06/20(金) 20:22:24.13ID:JSi28Lkj最後と言ってたのにやっぱり出てきた。バカ見苦しいぞ。ｗｗｗ
> 無限に
> 無限に
> 無限に
> 無限に
> 無限に
0892デフォルトの名無しさん
2014/06/20(金) 20:25:18.42ID:OK+lAQ+1わっかんねー
0893デフォルトの名無しさん
2014/06/20(金) 20:25:51.90ID:9kUUzjJLちゃんとしたヤツならソケットオプションでタイムアウトを設定するでしょ。
>>888
blocking I/Oに複雑怪奇で挙動不審なスレッド実装
何も分かっていない素人ほど複雑な実装をする
0894デフォルトの名無しさん
2014/06/20(金) 20:28:16.42ID:JSi28Lkj0895デフォルトの名無しさん
2014/06/21(土) 00:24:24.12ID:mv9//OJ7そっから>>824,835,844,853,860と流れ
>>860はID:JSi28Lkj
>>886で>>883で書いた処理は「ブロッキングI/Oで書いてあるのは一目瞭然。」
という墓穴を掘り
しかも
>>844の
> if (read(s, &size, sizeof(size)) != sizeof(size))
> error();
>>883の
> if ((cc = read(s, buf + l, sz - l)) < 1)
> return 0;
まだ何も理解していないらしい
0896デフォルトの名無しさん
2014/06/21(土) 00:32:58.75ID:q5PhIp9u非同期とノンブロッキングの違いを知らないバカは引っ込んでいなさい。
0897835
2014/06/21(土) 01:48:01.43ID:nSPSSkcc>>>860はID:JSi28Lkj
>>860カキコは、自分(>>853)のアンカ間違いが原因
>>860が間違いを指摘してくれたので、>>863で訂正した
0898デフォルトの名無しさん
2014/06/23(月) 12:37:22.72ID:XKl4yasNTCPのタイムアウトはソケットオプションにないよ、
って思ったら、Linuxではちょっと前から追加になってるのね。
0899デフォルトの名無しさん
2014/06/23(月) 13:07:02.22ID:HIGf9m9i0900デフォルトの名無しさん
2014/06/24(火) 00:37:23.49ID:6s1BpAfuそれぞれ送信、受信のタイムアウトだよ
0901デフォルトの名無しさん
2014/07/22(火) 10:03:57.24ID:8Q3uJhWXデータが欠損してる気がする
ローミング時の挙動ってどうなんだろう？
0902デフォルトの名無しさん
2014/07/22(火) 11:48:50.67ID:lgTh8/Jmなら、欠損することについてはTCPもUDPも区別なく、IPパケットなら起こりうるよ
ただし、TCPはreceiverからACKがこなければsenderは再送するという
機能があり、データがちゃんと送信されることが保証されてる
TCPについてなにか勘違いしてないか？
0903デフォルトの名無しさん
2014/07/22(火) 21:10:24.05ID:vNYu1ctv>>902でおおむね正しいけどあえて補足すると、TCPはコネクション指向プロトコルだから
「TCPコネクション上での通信に限って」データ損失の無い事が保証されている
だから、ローミングであろうが「TCPコネクションさえ維持できていれば」
TCPレベルでのデータの欠落は起きえない(もし起きたらそれはTCPスタック実装のバグ)
しかしそれでもユーザから見ればデータが欠落しているとしか思えない現象が起きる事はある
これはアプリケーション設計の失敗であることが多い(もちろんTCPスタックのバグかもしれない....)
有線ネットワークとは異なり、無線ネットワーク上での通信は電波状況の変化によって
「頻繁にTCPコネクションが切断される」から、モバイル対応アプリ開発においては
この無線ネットワーク固有の状況に対応できるよう設計しなければならない
たとえば有線ネットワーク上で巨大なファイルを転送したい時には FTP が使われることが多いけど、
数分から数十分にわたるファイル転送処理中に一度でも電波状況が悪くなれば失敗するから、
無線ネットワーク上では役に立たないケースが多い
これの対処方法は定番から特殊なプロトコルまでいくつかあるけど、こういった検討課題に
気付かず設計された通信システムだと、データの欠落を原因とする障害は頻繁に起こりうる
0904デフォルトの名無しさん
2014/07/22(火) 21:46:38.65ID:m2X37Pt+0905デフォルトの名無しさん
2014/07/22(火) 21:59:21.87ID:zC8syPvs0906デフォルトの名無しさん
2014/07/22(火) 22:00:41.38ID:gLVnM0Vt0907デフォルトの名無しさん
2014/07/22(火) 22:08:10.13ID:/QF06o+eちなみに端末は悪名高きiPad
APメーカーが言ってたけど
APが相手に見えないように存在消してるのに
接続しにくるみたい
昔のTCPでも欠損する winsock思い出した
0908デフォルトの名無しさん
2014/07/22(火) 22:35:12.36ID:/QF06o+eちなみに 1つ10万以上するAPを
そこそこの数使ってるから
切断は ほぼない(想定内のエリアなら)
チェックサム付けたけどデータ狂う
0909デフォルトの名無しさん
2014/07/22(火) 22:49:56.54ID:hoMdn42aTCP/IPとモバイルプロトコルが分かってないのだろう
0910デフォルトの名無しさん
2014/07/23(水) 06:36:18.15ID:37asru4I> 1つ10万以上するAPを
なんで、この手のアホは型番書かないんだろう...
0911デフォルトの名無しさん
2014/07/23(水) 09:12:30.49ID:oA1ueuw9TCPやネットワークの問題だったことは一度もない。
たいていはsocketの使い方を間違えている。
0912デフォルトの名無しさん
2014/07/23(水) 10:07:59.35ID:m2ygW4DO0913デフォルトの名無しさん
2014/07/23(水) 18:47:22.83ID:EQ67YqPb途中が欠損することはないが欠損以降が全く来ない事はある。
0914デフォルトの名無しさん
2014/07/23(水) 19:08:27.52ID:SLj4nbIO0915デフォルトの名無しさん
2014/07/23(水) 20:39:00.57ID:vSOuwJl20916デフォルトの名無しさん
2014/07/23(水) 20:42:09.93ID:Y8sMWbLm0917デフォルトの名無しさん
2014/07/24(木) 09:59:13.77ID:rCcZLsKC0918デフォルトの名無しさん
2014/07/24(木) 10:05:55.74ID:b1nwvn720919デフォルトの名無しさん
2014/07/24(木) 10:41:06.80ID:f/H2aifY0920デフォルトの名無しさん
2014/07/24(木) 10:49:22.16ID:dgV+vw+i0921デフォルトの名無しさん
2014/07/24(木) 21:34:45.24ID:rO5lcI/mケーブル抜けてるよ
0922デフォルトの名無しさん
2014/07/24(木) 22:28:02.03ID:6eyTGVml0923デフォルトの名無しさん
2014/07/25(金) 00:05:24.44ID:cQJQccdW0924デフォルトの名無しさん
2014/07/25(金) 00:38:37.79ID:JGW0iq/W0925デフォルトの名無しさん
2014/07/25(金) 07:42:28.86ID:vg9xmyXR0926デフォルトの名無しさん
2014/07/25(金) 07:46:42.85ID:6iRU1OZjペルチェ効果
ピエゾ効果
トムソン効果
>>925 に寄与するのはどれでしょう
0927デフォルトの名無しさん
2014/07/27(日) 00:47:33.80ID:yUcSBAyVねえよ、バーカ
0928デフォルトの名無しさん
2014/07/27(日) 14:27:54.75ID:A4exl8IK0929デフォルトの名無しさん
2014/07/27(日) 15:01:46.62ID:yKnfO4Xf0930デフォルトの名無しさん
2014/10/19(日) 09:09:45.23ID:y7reFn4b・やりたいこと
IPエイリアスで複数アサインしたIPアドレス毎にU)ユニキャストとM)マルチキャストを送受信したい。
・試したこと
1) bind時にIPアドレスを指定(NO-2)
→M)マルチキャストが受信できない
2) UDPの場合はSO_REUSEADDRで同じポートを指定しても良い(NO-4)そうなので指定。
→M)マルチキャストが受信でき、希望通りの動作になった
★U)ユニキャストはNO-3で指定したインターフェースしか受信出来ないのは正しい動作か？
コードの概要は以下の通りです。
#define ETH0_IP "192.168.0.1"
#define ECH00_IP "192.168.0.2"
sock = socket(AF_INET, SOCK_DGRAM, 0);
#ifdef ANY_ADDR
setsockopt(sock, SOL_SOCKET, SO_REUSEADDR, (char *)&opt, sizeof opt); // NO-4
#endif
addr.sin_family = AF_INET;
addr.sin_port = htons(3610);
#ifdef ANY_ADDR
addr.sin_addr.s_addr = INADDR_ANY; // NO-1
#else
addr.sin_addr.s_addr = inet_addr(ETH0_IP); // NO-2: eth0
#endif
bind(sock, (struct sockaddr *)&addr, sizeof addr);
mreq.imr_interface.s_addr = inet_addr(ETH0_IP); // NO-3
mreq.imr_multiaddr.s_addr = inet_addr("224.0.23.0");
setsockopt(sock, IPPROTO_IP, IP_ADD_MEMBERSHIP, (char *)&mreq, sizeof mreq);
recvfrom(sock, buf, sizeof buf, 0, (struct sockaddr *)&from, &addr_len);
0931デフォルトの名無しさん
2014/10/19(日) 10:34:01.70ID:rIEYfS5c0932デフォルトの名無しさん
2014/10/19(日) 21:12:24.57ID:y7reFn4b> 2) UDPの場合はSO_REUSEADDRで同じポートを指定しても良い(NO-4)そうなので指定。
> →M)マルチキャストが受信でき、希望通りの動作になった
> ★U)ユニキャストはNO-3で指定したインターフェースしか受信出来ないのは正しい動作か？
今日試したらNGでした（昨日は何度も確かめたのですが）、、、
ANY_ADDRでない場合、マルチキャストを受信できるようにするにはどうしたらよいのでしょうか？
そもそも「addr.sin_addr.s_addr」には、受信（送信）したいIFのIP{アドレスを指定するのですよね？
以下のように指定してもマルチキャストが受信できるのは正しい動作なのでしょうか？
addr.sin_addr.s_addr = inet_addr("224.0.23.0");
ちなみにubuntu14.04 32bit版で試しています。
0933デフォルトの名無しさん
2014/10/21(火) 07:44:23.09ID:KKrNe4lRpromiscuousはキャプチャ用途しか使ったことがないのですが、
promiscuousで受信して、送信は普通のsocket使えばよいのですか？
検索したらrecvmsg()を使う記事がありました。
とりあえず、ユニキャスト受信用のsocketとマルチキャスト受信用のsocketの2個使えば出来そうなことがわかりました。
＃マルチキャスト用のsocketを SO_REUSEADDR 指定
0934デフォルトの名無しさん
2014/10/21(火) 17:54:02.03ID:QuOrKhyR0935デフォルトの名無しさん
2014/10/26(日) 20:22:36.66ID:RQyk7KlL下記のプログラムを実行すると、データを末尾まで取得していないにもかかわらず、ループから抜ける事があります。
readByteCount == 0 のみをループの脱出条件にすると、Readで止まって（恐らくタイムアウト待ちになって）しまいます。
データを末尾まで確実に受取るにはどうすればよいのでしょう？
TcpClient client; // 接続処理、略
SslStream stream; // clientとの関連付け処理、略
byte[] command = Encoding.UTF8.GetBytes( ”__TAG__ FECTH ...略” );
stream.Write( command );
byte[] byteBuffer = new byte[ 256 ];
int offset = 0;
while ( true )
{
int readByteCount = stream.Read( byteBuffer, offset, byteBuffer.Length - offset );
offset += readByteCount;
if ( client.Available == 0 ||
readByteCount == 0 )
{
break;
}
if ( offset >= byteBuffer.Length )
{ // バッファの拡張処理 }
}
0936デフォルトの名無しさん
2014/10/26(日) 21:15:04.04ID:kiy4PZ8gお前にはいろいろな意味でムリだからプログラミングなんか止めてハローワークに行け
0937デフォルトの名無しさん
2014/10/26(日) 21:20:17.41ID:RQyk7KlL0938デフォルトの名無しさん
2014/10/26(日) 21:41:50.32ID:fx3FFnF6・バッファに書き込んだ量がバッファと同じかより長いときにバッファの拡張処理って、バッファオーバーフローでも期待してんの？
SslStream.Readに渡すバッファと、読み込んだデータを貯めこむバッファを分けるとかしとけ。
・TcpClient.AvailableってSSL使ってる時に読むものではないだろうし、そもそも終了処理に使うものでもない。
読み込みのほうが早くてバッファが一時的に空になれば何時でも0になる。Stream.CanReadとかTcpClient.Connectedとかだったかな。
ストリームなんだし、その接続上で次の作業が出来る状態ならSslStream.Readで止まるのは正常。
受け取った内容を見てメッセージが揃ったら処理を行ってから次の受信をするとか、
自動で切断するような要求にするとかしとけ。具体的に何の通信してるかしらんからそこら辺までは知らん。
0939デフォルトの名無しさん
2014/10/26(日) 21:50:44.31ID:RQyk7KlLレス有難うございます。
取得している内容はIMAPコマンドのレスポンスです。
データをパースすれば末尾かどうか判断がつきますが、パースは受信後の処理と考えていました。
読み込みながらパース、ってプログラムが複雑になります。
サーバー側の送信が終わったかどうかを検知できればいいと思っていたのですが、不可能なのでしょうか。
レス数が900を超えています。1000を超えると表示できなくなるよ。