トップページ⇒tech
1001コメント341KB

ネットワークプログラミング相談室 Port26

■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん2010/03/23(火) 20:31:49
主にソケットに関しての質疑応答スレッドです。

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辺り
足りなかったら適当に付け足してね

前スレ
ネットワークプログラミング相談室 Port25
http://pc12.2ch.net/test/read.cgi/tech/1255459388/
関連スレ
ネットワークプログラミング雑談
http://pc12.2ch.net/test/read.cgi/tech/1235800707/
Java ネットワークプログラミング 【教えて!】
http://pc12.2ch.net/test/read.cgi/tech/1086238859/
0412デフォルトの名無しさん2010/06/06(日) 11:01:33
>>411です。
ああ、頻繁じゃなくてもいいです。タイマーか何かで定期的にチェックして
その結果でフラグセットしますので。
0413デフォルトの名無しさん2010/06/06(日) 13:14:53
>>405
ネット情報すべて解析する技術　利用者から「使用やめろ」の大合唱
6月5日18時12分配信 J-CASTニュース

だが通信の秘密は、通信当事者の同意があれば侵害とはならない、とも書かれていた。こうなると、同意があればDPI技術を利用してよいと読み取れなくもない。
総務省はDPIによる行動ターゲティング広告を容認したのだろうか。
総務省消費者行政課に取材すると、「そのような事実はありません」と明確に否定した。

　同課によると、そもそも「提言」は、DPIの課題を研究会で検討した内容を整理したものに過ぎず、この段階で「容認した」という類のものではない。それを踏まえたうえで、「同意」の内容について大変厳しい解釈を示していると主張する。
例えばサイト上での周知だけ、契約約款に規定を設けるだけでは「同意あり」とはみなさないという。
一方で、ISPと新規契約する際の契約書に、「行動ターゲティング広告への利用を目的として、DPI技術を使って通信情報を取得することに同意する」という欄を設けた場合は、
「個別かつ明確な同意」として認められるという。仮に同意した後でも、「やはりDPIの使用はやめてほしい」となれば簡単に中止を求められる「オプトアウト」の機会を提供するよう、ISPに求めるとしている。
これらは、「一部の法学者から『厳しすぎる』との声があったほど」（消費者行政課）高いハードルだという。
0414デフォルトの名無しさん2010/06/06(日) 15:17:34
リアルだと警察が街中に監視カメラ設置して、個人商店には警察協力と称して設置を強要してやりたい放題でしょ。
警察がやりたい放題になっている社会の方が問題だと思うよ。
イスラエルとかジャマイカとかだと警察官が気に食わない奴の家に上がりこんでそいつを当たり前の表情で殺してる。
日本だと警官が人殺しをすることは無いけど、警察利権を作るだろうね。たとえば交通道路とか風俗・警備会社許認可権、最近だと監視カメラ利権でしょ？
銃刀法も扱ってるから、例えばなんでもないプラモデル屋やフィギア屋にすら「ナイフだろ！」とか言いがかりつけて、気に食わなければ逮捕とかも可能だろうね。
警察が幅を利かせるようになると国家の監視どころじゃなく警察に統治されるようなそういう世界がまっている。
ネットよりリアルの方が窮屈で監視社会（全体主義的な検閲社会）になってるなって感じはする。
0415デフォルトの名無しさん2010/06/06(日) 15:28:39
>>411
netsh
0416デフォルトの名無しさん2010/06/07(月) 01:15:42
>>411
acceptして放置
0417デフォルトの名無しさん2010/06/07(月) 01:19:22
ネットワークを扱った書籍で、子供だましな誰得？なｻﾝﾌﾟﾙｱﾌﾟﾘとか
やってはいけない馬鹿の見本なｻﾝﾌﾟﾙｺｰﾄﾞとかじゃなく
まじめにきちんと設計されたアプリを書き上げた書籍ってありますか？
0418デフォルトの名無しさん2010/06/07(月) 01:44:33
>>417
UNIXネットワークプログラミング<Vol.1>
がもっとも要求に近い。
0419デフォルトの名無しさん2010/06/07(月) 05:13:07
>>417
なんでオープンソースのコードを読まないの？
0420デフォルトの名無しさん2010/06/07(月) 19:55:48
TCPDUMPについて質問させてください

tcpdumpからソースIPとあて先IPをスプリクトで抜き出し
エントロピー値を取ろうと思うのですが

スプリクトは直接TCPDUMPは読み込めないので
tcpdumpをｔｘｔファイルに変換させることは可能でしょうか？

Wiresharkで読み込ませて、txtにしようと思ったのですが
うまく行きません

レベルの低い質問ですが
どうかご教授お願いします
0421デフォルトの名無しさん2010/06/07(月) 20:04:02
>>418,419
半角カタカナという基本的なネットのリテラシも無い、やってはいけない馬鹿の見本のような
カキコを平気でする>>417みたいなのに何を言っても無駄なだけ。
>>418の挙げた書籍には大いに同意するし自分にはバイブルだったけど>>417には豚に真珠。
>>419が何を言っても馬の耳に念仏だお。
0422デフォルトの名無しさん2010/06/07(月) 20:30:14
近所にﾐﾆﾌﾞﾀ飼ってて奥さんが颯爽と散歩兼ねてｼﾞｮｷﾞﾝｸﾞしてる。
真珠かｲﾐﾃｰｼｮﾝか知らんが結構似合うﾓﾝだぜ？豚に真珠。
0423デフォルトの名無しさん2010/06/07(月) 20:38:55
で、>>417には似合うのか？
0424デフォルトの名無しさん2010/06/07(月) 20:54:13
>>420
IPってゆうな。クズ。
0425デフォルトの名無しさん2010/06/07(月) 23:06:15
>>420

スクリプトから直接読み込みたけりゃリダイレクトして標準入力から読めばよろし

ファイル経由でよいならtcpdumpの出力をファイルに落とすオプションがあったと思うぞ
0426デフォルトの名無しさん2010/06/07(月) 23:43:59
そういえば、「バイト数の節約になるんだ」とかいって
EUCやUTF8でも半角かなを使っている人がいたな。
今でも元気にしてるかな・・・
0427デフォルトの名無しさん2010/06/07(月) 23:49:13
そういう奴ほど元気で長生きなものだ
0428デフォルトの名無しさん2010/06/07(月) 23:50:15
半角ｶﾅ駄目とかいう暴論者は10年ほど前に絶滅したと思ったらまだいたんだな…
0429デフォルトの名無しさん2010/06/07(月) 23:52:00
半角かなの特性を正しく理解せずに使っているのが癇に障るんだろう
0430デフォルトの名無しさん2010/06/07(月) 23:55:30
今時7ﾋﾞｯﾄしか受け付けないﾒｰﾙｻｰﾊﾞなんてあるんですか？
0431デフォルトの名無しさん2010/06/07(月) 23:57:46
悪魔の証明は不可能だよ
0432デフォルトの名無しさん2010/06/08(火) 00:02:52
そういえば外人って°とか℃とか㎡とかどうやって入力してるんだろう？
0433デフォルトの名無しさん2010/06/08(火) 00:32:10
degreeとかdegree celsiusとかsquare meterとか書いちゃうよｗ
0434デフォルトの名無しさん2010/06/08(火) 01:32:36
>>421のせいで基本的なネットのリテラシも無い、やってはいけない馬鹿の見本のような
カキコを平気でする奴が出てきた。もう何を言っても馬の耳に念仏だお。
0435デフォルトの名無しさん2010/06/08(火) 08:19:40
>>420
tcpdump > tcpdump.txt
0436デフォルトの名無しさん2010/06/08(火) 09:17:04
結局半角カナを使う馬鹿って生き残っちゃったよな
0437デフォルトの名無しさん2010/06/08(火) 09:58:26
>>436
(ﾟ∀ﾟ)これも半角だしNE!
0438デフォルトの名無しさん2010/06/08(火) 09:58:26
文字コードとして割り当てがあるのに使ってはいけないとか言う子の意図がわからんな
0439デフォルトの名無しさん2010/06/08(火) 10:03:53
>>438
8bit->7bit変換のときに単純に8bit目を落とす馬鹿鯖があるからだろ
0440デフォルトの名無しさん2010/06/08(火) 10:27:00
ISO-2022-JPでは使わないことになってるエスケープなのに、使っていいとか思ってる子の意図がわからんな
0441デフォルトの名無しさん2010/06/08(火) 11:44:09
>>440
ISO-2022-JP以外なら使ってもいいってことだから問題ないよ。
ISO-2022-JPに変換しなければおｋ
0442デフォルトの名無しさん2010/06/08(火) 11:52:15
バカっぽく見えるから使わない方がいいよ。逆にバカっぽさを強調したい場合には使うのもあり。
0443デフォルトの名無しさん2010/06/08(火) 12:31:39
こいつらの作るアプリはさぞ使いにくいだろうなｗ
0444デフォルトの名無しさん2010/06/08(火) 13:52:53
黙れ
ﾈﾄｳﾖ
0445デフォルトの名無しさん2010/06/08(火) 14:22:12
>>444
極めて正しい用法。
0446デフォルトの名無しさん2010/06/08(火) 14:34:03
>>442
ｲｯﾃﾖﾁ!
0447デフォルトの名無しさん2010/06/08(火) 18:19:01
>>442
半角かなを使わないに越したことは無いが
半角かなを受け入れられないソフトは糞だ。
0448デフォルトの名無しさん2010/06/08(火) 18:37:39
半角ｶﾅ駄目とか30年前からタイムスリップしてきたのか？ｗ
0449デフォルトの名無しさん2010/06/08(火) 18:57:57
半角カナ使う奴の方が30年前からタイムスリップして来てるのだが
0450デフォルトの名無しさん2010/06/08(火) 19:53:41
両方使えるようにすればいいだけじゃん。
エンドユーザーなんて何するかわからん。
0451デフォルトの名無しさん2010/06/08(火) 21:46:57
㍼ｽﾚ？
0452デフォルトの名無しさん2010/06/08(火) 21:58:09
>>440
つまり①②……も禁止か？"－"もだめそうだが？
0453デフォルトの名無しさん2010/06/08(火) 22:04:14
潔く捨てるのがルータの教え。
利用者に使えないんだと理解させるためにicmpで通知してあげればいい。
0454デフォルトの名無しさん2010/06/08(火) 22:06:26
icmpてピングでしょ？どうやって通知するの？
0455デフォルトの名無しさん2010/06/08(火) 22:10:29
昔はメールを書く時には半角カタカナや機種依存文字を使うなとしつこく言われたものけど、
最近は初体験で日常的なメールというのがケータイであるという奴が増えているから、
半角カタカナや絵文字について何も違和感を持たず、同じ感覚で2chにカキコしてるんだろね。
で、社会人になってから、常識の無い奴とドヤされるわけだ。
0456デフォルトの名無しさん2010/06/08(火) 22:14:26
昭和時代はカタカナでメールを打つのが常識だったんですか？
0457デフォルトの名無しさん2010/06/08(火) 22:35:17
ポケベルで数字打つってのが常識でした。
0458デフォルトの名無しさん2010/06/08(火) 22:39:27
53 93 65 05
0459デフォルトの名無しさん2010/06/08(火) 23:38:50
実に滑稽ｗ
そのうち時代後れな事を言ってる奴が”文字化けするから「表」「予」「申」「能」「十」「ソ」なんかの文字も使うな！”とか言いだしそうだぜｗ
0460デフォルトの名無しさん2010/06/08(火) 23:43:18
\表
0461デフォルトの名無しさん2010/06/08(火) 23:56:26
森鴎外叱る
0462デフォルトの名無しさん2010/06/09(水) 00:00:06
>>459
俺鬱
JIS-X2010
0463デフォルトの名無しさん2010/06/09(水) 00:04:13
>>459 半角カナを使うような無神経な奴ほど、トラブルに対してそういう対応をするけどな。俺の経験上。
0464デフォルトの名無しさん2010/06/09(水) 00:27:49
エスケープするなら表\だろ。
0465デフォルトの名無しさん2010/06/09(水) 01:01:47
>>463
おまえの負け
0466デフォルトの名無しさん2010/06/09(水) 15:59:50
検索で半角カナと全角カナを厳密に区別するソフトとかあるからなー
必要に迫られない限り、使わないにこしたことないでしょ。機種依存文字なんだし
0467デフォルトの名無しさん2010/06/09(水) 17:44:39
バカっぽい雰囲気を出したいときは必須。
0468デフォルトの名無しさん2010/06/09(水) 17:52:08
一般の人の反応：　昔は使えなかったとかごちゃごちゃ言ってるけど、
今は使えてるんだからい～じゃん、あほくさ
0469デフォルトの名無しさん2010/06/09(水) 19:17:06
>>420
Wireshark(Ethereal)に付いているコマンドラインツールのどれかに、
そういう機能があったと思う。

Wireshark Manual Pages
ttp://www.wireshark.org/docs/man-pages/
0470デフォルトの名無しさん2010/06/10(木) 10:46:48
ﾌﾟｹﾞﾗ
0471デフォルトの名無しさん2010/06/11(金) 01:21:14
初歩的な質問
UDPのパケットがフラグメントとかされて途中で分断されてても
アプリケーション層でrecvfrom成功した時は送信されたパケットと同じサイズの
データの取得は保証されてる？

UDPはパケットの到着順は保証されないけど、パケット単位での再結合が成功済みの
パケットしかアプリケーション層までは到達しないんだよね・・・？
0472デフォルトの名無しさん2010/06/11(金) 01:27:40
眠いのかい？
0473デフォルトの名無しさん2010/06/11(金) 01:47:34
>>471
到達しない。

というか、フラグメンテーションはIP層で行われているからUDPは
完全なIPパケットしかもともと受け取らない。
0474デフォルトの名無しさん2010/06/11(金) 09:01:50
>>473
thx

さらにもう一個質問。

PC Aが100byteのUDPパケットをPC C Port1234に送信
PC Bが100byteのUDPパケットをPC C Port1234に送信

PC CがPort1234からrecvfromで50byteずつ取得、ってケースだと
Aの最初50>Bの最初50>Aの最後50>Bの最後50
とかの順番で取得されるケースもありえる？
ありえるならUDPの受信ってテンポラリバッファ＋送信元IP/Port毎の独立バッファ
で受信しないといけなくて凄く実装が面倒なんだけど・・・
0475デフォルトの名無しさん2010/06/11(金) 09:14:32
>>474
ない。
もしどっかでちょん切れたら最後の50はうしなわえう
0476デフォルトの名無しさん2010/06/11(金) 10:45:36
＞もしどっかでちょん切れたら最後の50はうしなわえう
ちょっと待て。
「最後の50」だけ失われるケースはありえないだろ。

ちょん切れて飛んできても勝手に結合してくれるし、もし結合できなかったら「最初の50すら捨てる」だろ。
そうじゃなきゃUDP使えないってのｗ
0477デフォルトの名無しさん2010/06/11(金) 11:21:44
データ部が548バイトまでなら絶対分割されないから、分割が心配ならそのサイズまででやればいい。
548バイト超えると分割されたり、再送がどうだの発生したりで性能劣化していくし

あってるよね？
0478デフォルトの名無しさん2010/06/11(金) 17:02:49
IPヘッダ内に「分割(フラグメント)可否フラグ」というのが存在している。
サブネット間に位置するルータは、パケット転送時に分割が必要な場合、
このフラグを参照し、もし不可であれば単純にそのパケットを破棄する。
で、一般的なUDP実装では、このフラグは「常に」不可に設定される。
だから(>>474のような)ネットワーク上を分割されたUDPデータグラムが
流れる現象そのものが起こりえない。

ただし、このフラグを許可に設定するような「行儀の悪い」UDP実装が
送信者であった場合、どうなるかは知らない(予測できない)。
分割されたUDPデータグラムを単純に破棄する受信者が大半であると思われる。
0479デフォルトの名無しさん2010/06/11(金) 20:26:35
>>476
分割するハメになったら破棄されるんだから、結合はないよね？
もしかしてあるの？
0480デフォルトの名無しさん2010/06/12(土) 10:35:20
パケットロスや順番入れ替えが無かったと仮定して。
sendtoで"A""B"..."Z"と一文字ずつ26回送った場合
受信側はrecvfrom一回で"ABC..."とかくっついて受信されずに
recvfromを26回、一回につき一文字ずつ受信できるのは保証されてるのかな？

TCPだとrecvの戻りはいくつかのパケットがくっついたりパケットの途中で戻ってくるけど
UDPではsendto/recvfromは1:1対応してる、と想定して作っていいんだよね？
0481デフォルトの名無しさん2010/06/12(土) 11:45:55
そもそも、そんなことを気にしなきゃならないような通信を
UDPで実装しようって設計が間違ってる気がする
0482デフォルトの名無しさん2010/06/12(土) 11:59:34
>>480
それが書いていない教科書はクソだし、検索すればいくらでも出てくる。
0483デフォルトの名無しさん2010/06/12(土) 12:04:43
>>480
作るときはパケットの区切りは、どこか分からないものとして作るんだよ
ここが区切りですなんて情報はくっついて来ないから


入り口から入れたものが同じ順番で出口からでてくるのがTCP
順番が狂ったり出て来ないのがあるのがUDP
そんだけ
0484デフォルトの名無しさん2010/06/12(土) 12:30:19
>>483
> 作るときはパケットの区切りは、どこか分からないものとして作るんだよ
それはTCPだけ。　UDPはおk。
0485デフォルトの名無しさん2010/06/12(土) 12:40:33
>>482
とりあえず１冊入門書読んだんだけど見つからなかったんだ・・・
UDPのRFC読んだけどそう動作するよう実装するべし、みたいなのが見つからなくって
ネットで探した限りSUNのページにそれらしい記述があったけどSUNの実装が
そうなってるだけでBSDソケットと名乗るなら必ずそう動作する、って保証はあるのかなぁ、と

>ただし、このフラグを許可に設定するような「行儀の悪い」UDP実装が
みたいにソケット実装者の気分次第でどう動作するように実装してもよくて
たまたま多くの実装がそうなってるだけとかだと嫌だなぁと
0486デフォルトの名無しさん2010/06/12(土) 13:00:20
>>485

スタックを使う側はそういうのは考えなくてよろしいのよ

スタック自体を実装するのなら、思いっきり考えてくださいまし

自分とこで使ってるスタックの実装に合わないパケットはスタックが捨ててくれるんだから
よそ様が何をつかってても関係ないでしょ
0487デフォルトの名無しさん2010/06/12(土) 13:04:31
>>485
UNIXネットワークプログラミング<Vol.1>
を買ってこい。今すぐ！ダッシュでだ！
0488デフォルトの名無しさん2010/06/12(土) 13:08:52
>>486
UDPではsendto/recvfromは1:1対応してると期待していいのかどうか、
で使う側の実装はまったく違うものになると思うが・・・

で、二種類の異なるハード・ＯＳ（両方BSDソケットは使えると言ってる。ちなみにWinでもLinuxでも無い。CPUもIntelじゃない。）
がNAT下にあってUPnP/STANでNATのUDPの穴あけは相互にできるけどTCPは保証できない、
という環境でUDP使ってP2Pで通信してね、というお仕事を引き継いだんだけど
UDP使うの初めてで色々わからんのよ・・・
0489デフォルトの名無しさん2010/06/12(土) 13:26:39
>>488
>UDPではsendto/recvfromは1:1対応してると期待していいのかどうか、

それ以前に到達することすら保障されてないわけだが、そこはいいの？

良く分からない仕様で悩んでるよりも
出てきたデータをストリームとして扱えば、1対1だろうが多対１だろうが問題ないんじゃね？

0490デフォルトの名無しさん2010/06/12(土) 13:34:59
>それ以前に到達することすら保障されてないわけだが、そこはいいの？
UDP使うしか無い以上その保証はアプリ側で対処するしか無いです。車輪の最発明は嫌だけど・・・

>出てきたデータをストリームとして扱えば、1対1だろうが多対１だろうが問題ないんじゃね？
順番が保証されないデータのストリーム前提の実装って、無理じゃないけどえらい面倒＋メモリ＆ＣＰＵ資源の
無駄が多そう。あんまり富豪的なプログラムできるほどリッチなハードでも無いし。

BSDソケット使えると言ってるならアプリケーション層までたどり着いた
UDPパケットは1:1保証されてるんだよ、となればその前提で組めるので
助かるなぁ、と・・・

0491デフォルトの名無しさん2010/06/12(土) 13:42:53
>>488
期待しなきゃだめだろ
その代わり順番も入れ替わるし無くなることもあるというだけの話
0492デフォルトの名無しさん2010/06/12(土) 14:21:44
>>491
だよね

前任者のコードで
struct hoge {
int tag;
int size;
char data[0];
};
char buf[512];
int size = recvfrom(buf,sizeof(buf),ip,port);
if (size >= sizeof(hoge) && ntohl(((hoge*)buf)->tag) == TAG && ntohl(((hoge*)buf)->size) == size) {
//受信処理
}
みたいなコードがあって
TCPではこの作りダメだけどUDPならいいのかな？と疑問だったけど
UDPのsendto/recvfromは1:1対応を期待できるなら大丈夫だね。
0493デフォルトの名無しさん2010/06/12(土) 15:14:45
>>492
rfc1180
UDP preserves the message boundary defined by the application. It
never joins two application messages together, or divides a single
application message into parts.

後、キミはBSDソケットの位置づけを誤解している。
0494デフォルトの名無しさん2010/06/12(土) 17:24:35
>>478
> で、一般的なUDP実装では、このフラグは「常に」不可に設定される。
いつからそうなった?

少なくとも, 4.2 BSD の実装時点ではそうできてないし,
unix 系の実装でそうなっているやつは見かけないんだが...

で, 今, 手元にある FreeBSD あたりだと
% sysctl net.inet.udp.maxdgram
net.inet.udp.maxdgram: 9216
てなことになってるが
0495デフォルトの名無しさん2010/06/12(土) 18:20:02
>>493
RFC1180にあったのか。これってTCPだけじゃなくUDPについても書いてあったんだね。
UDPだからRFC768を見てた。さんくす

>後、キミはBSDソケットの位置づけを誤解している。
SDKのドキュメントに"BSDソケット準拠のソケットライブラリ"と書かれていたから
"ANCI準拠"とかと同じ統一規格の一種かと思ってたんだど、誤解かな？
0496デフォルトの名無しさん2010/06/12(土) 20:23:52
>>495
BSDソケットはAPI, プロトコルではない。

> BSDソケットと名乗るなら必ずそう動作する、って保証はあるのかなぁ、と
という表現はおかしい。
0497デフォルトの名無しさん2010/06/12(土) 20:44:30
> BSDソケットはAPI, プロトコルではない。
「Berkeley 互換を名乗るなら動作を含めて互換にしてほしい」ってのはわがまま?
組み込み用途のスタックとか Berkeley 互換をうたいながら全然互換じゃない実装って結構あるのな
まぁ, メモリに余裕があれば移植してしまえば済む話ではあるが...
0498デフォルトの名無しさん2010/06/13(日) 11:54:44
> 「Berkeley 互換を名乗るなら動作を含めて互換にしてほしい」ってのはわがまま?
やっぱりAPIだと言う事を理解していない
APIだから、socket(PF_INET,...)がEPROTONOSUPPORTを返したってBSDソケットの正しい実装。
0499デフォルトの名無しさん2010/06/13(日) 12:10:10
APIって、セマンティック含めてAPIだろ。
名前が同じならいいってもんじゃない。
0500デフォルトの名無しさん2010/06/13(日) 12:35:56
BSDソケットは、特定のプロトコルの実装を要求していない。
0501デフォルトの名無しさん2010/06/13(日) 14:02:52
>>498
API ってのは, 仕様があってはじめて API って名乗れるもんではないのか?
Berkeley の仕様なんてどこにもないんだが…

# 強いて言えば, posix の要求仕様程度かな？

初期の Postscript 互換言語なんて bug も含めて互換性を求められてたぞ
xterm に至っては忠実に vt100 の bug まで再現してた
0502デフォルトの名無しさん2010/06/13(日) 14:17:33
下らない言いがかりをつけるのはキミの自由だけど、世の中の大部分の人はAPIだと考えている。
http://en.wikipedia.org/wiki/Berkeley_sockets

どうしてもBSDソケットはAPIじゃ無いと言いたいなら、理由を列挙して署名入り記事でも発表しなよ。
0503デフォルトの名無しさん2010/06/13(日) 15:07:30
>>501
manすら見たことない事を全力で告白しなくても良いぞ。
0504デフォルトの名無しさん2010/06/17(木) 19:16:24
Windows でネットワークプログラミングを始めました。
Linux ではちょっとやっていたことがあります。

マルチスレッドで処理をしようと考えているのですが、Winsock のいくつかの関数がスレッドセーフなのかどうかがよくわかりません。
1つのスレッドで 1つの socket を扱っており、例えば recv の後で WSAGetLastError を呼び出しているのですが、
WSAGetLastError はスレッドセーフなのでしょうか。
スレッドセーフではない場合、どう対処するものなのでしょうか。

gethostbynameなどはスレッドセーフじゃないという情報があったので、mutex を使って排他しています。
しかしながら recv から WSAGetLastError までを排他すると、マルチスレッドのメリットが無くなってしまうんじゃないかと思う次第です
（この socket はブロックモードです）。
0505デフォルトの名無しさん2010/06/17(木) 19:36:19
>WSAGetLastError はスレッドセーフなのでしょうか。

いいえ

>スレッドセーフではない場合、どう対処するものなのでしょうか。

WSAGetLastError を使わない
0506デフォルトの名無しさん2010/06/17(木) 19:57:55
http://msdn.microsoft.com/en-us/library/ms741580%28VS.85%29.aspx

The return value indicates the error code for this thread's last Windows Sockets operation that failed.
05075042010/06/17(木) 20:14:20
英語はあんまり得意じゃないんで読み間違ってたらすみませんが、
>>506
>The return value indicates the error code for this thread's last Windows Sockets operation that failed.

for this thread's とあるので、「*このスレッド*で起きた最後の失敗理由を返す」って意味で合ってますか？
であればスレッドセーフってことなんじゃないかと思うのですが、どうなんでしょう？ >>505
0508デフォルトの名無しさん2010/06/17(木) 20:19:09
ただのアホの戯言ですよ
0509デフォルトの名無しさん2010/06/17(木) 23:48:19
>>502 すまんな、急な出張が入ってた
それは *nix とか, Windos とかの資源が潤沢なところの世界の話だ
0510デフォルトの名無しさん2010/06/18(金) 01:02:25
>>504
1つのスレッドで 1つのsocketを扱っているならWSAGetLastErrorを
複数スレッドで同時に呼んでも全く問題なし。
0511デフォルトの名無しさん2010/06/18(金) 01:13:42
1つのスレッドでWSAGetLastErrorを*同時に*呼ぶ事はできないから
WSAGetLastErrorの使用に関して条件を付ける必要は無い。
■ このスレッドは過去ログ倉庫に格納されています