ネットワークプログラミング相談室 Port24
■ このスレッドは過去ログ倉庫に格納されています
0001lmtp
2009/07/07(火) 00:46:28Programming 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辺り
足りなかったら適当に付け足してね
前スレ
ネットワークプログラミング相談室 Port23
http://pc12.2ch.net/test/read.cgi/tech/1230466044/
関連スレ
ネットワークプログラミング雑談
http://pc12.2ch.net/test/read.cgi/tech/1235800707/
Java ネットワークプログラミング 【教えて!】
http://pc11.2ch.net/test/read.cgi/tech/1086238859/
0693デフォルトの名無しさん
2009/09/09(水) 01:44:02> TCPで受信するときって、毎回受信サイズ違いますよね
> それらを一つのデータとしてバッファに入れる方法ってあるのでしょうか？
recvで受けたデータを順番にバッファに詰めていけばいいだけだろ。
ネットワークプログラミング以前のスキル不足じゃね？
0694デフォルトの名無しさん
2009/09/09(水) 01:49:13たぶん何をやりたいのか自分でもわかってないのが問題だとおもうけど。
TCPなら、それぞれのソケットから交互に1byteずつreadしていけばいいんじゃね？
0695デフォルトの名無しさん
2009/09/09(水) 01:54:46ＣＰＵが2個あるようなイメージの処理で
そういうのってやはり無理なのかなぁ。
そうでないと、送信と受信を同タイミングでする際、どちらかが終わってからじゃないと
処理できませんよね。送信→受信もしくは、受信→送信の流れに
0696デフォルトの名無しさん
2009/09/09(水) 03:51:51あとはソケットからの読み込みとかを組み込めば楽勝。
0697デフォルトの名無しさん
2009/09/09(水) 10:10:04最近javaでネットワークプログラミングを始めようと思っています。(TCP)
cのときは、ここの話題にも時々出てくるように長さプレフィックスつけたり、区切り文字使ったりとても苦労しましたが、
javaだと、Serializable、ObjectInputStreamといったものでオブジェクト渡せば悲しいぐらい簡単で、うまくいっているように見えます。
これは正解ですか？
0698デフォルトの名無しさん
2009/09/09(水) 10:18:57パフォーマンスとか効率とかを求めないなら、便利で楽で良いと思うよ
0699デフォルトの名無しさん
2009/09/09(水) 10:40:09fdopenしてstdioにバッファリングさせる。
0700デフォルトの名無しさん
2009/09/09(水) 10:57:11CPUが2つあってもネットワークインタフェースがひとつじゃあねぇ。
0701デフォルトの名無しさん
2009/09/09(水) 10:58:490702デフォルトの名無しさん
2009/09/09(水) 11:06:08>>691には関しての質問はないので、解決済みなんだろ。
0703デフォルトの名無しさん
2009/09/09(水) 11:12:08> 悲しいぐらい簡単
ﾜﾛﾀ
しかし C でも TLV とかにしてればさして苦労はしなかっ
たはずだぞ。マクロでなんとかなってた気がする。
0704デフォルトの名無しさん
2009/09/09(水) 11:37:44あと、Java以外のシステムと通信しないなら。
0705デフォルトの名無しさん
2009/09/09(水) 11:46:30話がかみ合ってないぞ
0706デフォルトの名無しさん
2009/09/09(水) 22:00:17ＡｃｔｉｖｅＸ無しでできる？
0707デフォルトの名無しさん
2009/09/09(水) 22:27:18例えばtelnetとかでアクセスすることも可能なわけで
telnetはサーバから何を受け取ってもIEを起動したりしないし
0708デフォルトの名無しさん
2009/09/09(水) 22:33:24＼ __ ／
＿ （ｍ） ＿ﾋﾟｺｰﾝ
|ミ|
／ ｀´ ＼
('A`) IEを強制起動するtelnetを
ノヽノヽ あらかじめ配布しておけば！
くく
0709デフォルトの名無しさん
2009/09/09(水) 22:34:09ノヽノヽ＝３ ブー
くく
0710デフォルトの名無しさん
2009/09/09(水) 22:44:50ありがと、サーバーもjavaで書くんで大丈夫そうです
パフォーマンスは気にならないわけではないが・・・まぁいっかｗ
>>703
TLVとか詳しくわからない・・・
まぁ何送るか教えて、(サイズ教えて)、データ送るようにはしてたが、
マクロとか使えるものが合ったのか・・・・
0711デフォルトの名無しさん
2009/09/09(水) 23:02:10ブロードキャストで送ると受信はされるのですが…
送信に関しては設定はいらないけど受信する場合は何か設定がいるのでしょうか？
0712デフォルトの名無しさん
2009/09/10(木) 10:08:350713デフォルトの名無しさん
2009/09/10(木) 11:15:43一種のウィルスだな、それは。
0714デフォルトの名無しさん
2009/09/10(木) 22:16:06できるわけねーだろクソガキ消えろ
0715デフォルトの名無しさん
2009/09/10(木) 23:06:520716デフォルトの名無しさん
2009/09/10(木) 23:50:12> まぁ何送るか教えて、(サイズ教えて)、データ送るようにはしてた
TLV は type, length, value だからそんなもん。
メリットとしては新旧バージョンが混在しても
TL の部分で読み飛ばし判定が出来るってことかな。
だから構造体みたいなのは構造体ごと読み飛ばせるように
中の要素サイズも含めたサイズを指定することになる。
0717デフォルトの名無しさん
2009/09/10(木) 23:57:31マルチキャストアドレスグループの参加の方法ってどうやるのでしょうか？
送信側は参加に関係ないのかな
0718デフォルトの名無しさん
2009/09/11(金) 00:01:39とっておきの解説サイトを教えてやろう。
http://www.google.com/
0719デフォルトの名無しさん
2009/09/11(金) 00:14:24素人の知識で自慢するなかれ。笑われるよ。
0720デフォルトの名無しさん
2009/09/11(金) 01:08:46国際通信規格でも使われてますが何か?(ﾌﾟ
0721デフォルトの名無しさん
2009/09/11(金) 01:15:14その国際通信規格を>>679,710に勧める(自慢する)のが適切か？と言ってるだけ。
他の選択肢と比較した場合の利点と欠点を理解してるのか？
0722デフォルトの名無しさん
2009/09/11(金) 01:34:12・固定長
・区切りをつける（STX,ETXとか改行とかみたいな）
・ヘッダ＋ボディ構成（ヘッダ部に種別と長さみたいな）
くらいなもんじゃね？
TLV形式って名前は知らなくてもみんな無意識に
似たような実装してるだろ
0723デフォルトの名無しさん
2009/09/11(金) 02:03:59・オブジェクトマーシャリング -- >>679,710が選んだ方式で、言語が限定される
・テキスト -- Internetプロトコルで多用される(SMTP/HTTPなど)
・プログラミング言語様式の定義言語 -- 現在の主流(Protocol Buffer/IDL/XDRなど)
・形式的仕様記述言語 -- TLV方式(国際通信規格の名称はASN.1/BER)
後にいくほど、メッセージ形式仕様定義の厳密さは増すが、実装は困難になる。
だから安易にTLV方式を採用することで「みんな無意識に似たような実装して」
似たようバグを作り込んでいる。もしもTLV方式に固執しつつ、他の方式と同等な
品質も確保するのなら、ASN.1インスタンスをBERへ変換するC言語モジュールを
自動生成できるASN.1コンパイラを導入するしかないが、覚悟と準備が前提になる。
これらの事柄を理解した上で、その国際通信規格とやらを提案(自慢)するのか？と
言っているのだが。自分は、>>679,710が彼自身の置かれている現状の中で、
最良な方式を(無意識にせよ)選択したと考えたから、特にレスもせずスルーしたよ。
0724デフォルトの名無しさん
2009/09/11(金) 02:35:38似たようなバグってたとえばどんなの？
0725デフォルトの名無しさん
2009/09/11(金) 03:01:22TLV方式というのは、XMLと同じで柔軟で階層的なデータ構造を実現できる(これは利点)。
ただし、それだけでは、スキーマを決めずに(定義せずに)XMLでデータ交換するようなものだから、
通信相手相互の解釈の違いがバグに直結する。
解釈の相違について、具体的な例をあげる。
・このTypeは必須か/オプションか
・これらのTypeの並び順は規定されるか/自由か
・このTypeの重複は許すか/禁止するか(列の表現)
・このTypeの列の要素は多相を許すか/禁止するか
これらのデータ構造(構文)を形式的に定義するのが、ASN.1という言語。
XMLでいうDTD/RELAX-NG/XML Schemaといったスキーマ定義言語に相当する。
おそらく、これらが問題になるほどの複雑なメッセージ形式は必要ねえだろ？と
思うかもしれない。だとすれば(それほど単純なメッセージ形式であるならば)、
それは他の3つの方式を選択すべきで、あえて柔軟なTLV方式を選ぶこと自体が誤りである、
という結論になる。
0726デフォルトの名無しさん
2009/09/11(金) 03:13:10それを通信路上でやるだけ。
0727デフォルトの名無しさん
2009/09/11(金) 03:33:15DBスキーマは固定的(柔軟ではない)だよ。
通信であれば>>723の3番目にあげたProtocolBuffer/IDL/XDLに近い。
これなら、ある程度のプログラマなら対応できると思う。
ただ、ASN.1は(>>723で書いたように)、XMLスキーマに近い位置づけの言語。
そこらの人間だってDBスキーマくらいはやれるかもしれないけど、
XMLスキーマを自由に操れる人は、RDB屋さんほどありふれていないでそ。
XMLデータベースの普及を遅らせている、最大の要因だと思っているよ。
0728デフォルトの名無しさん
2009/09/11(金) 23:54:35単にTLVってType,Length,Valueの略ってわけじゃないの？w
0729デフォルトの名無しさん
2009/09/12(土) 00:08:500730デフォルトの名無しさん
2009/09/12(土) 00:43:05一般的には、ネットワーク上を流れるバイナリ形式のデータ構造表現法の一つ。
で、そのエンコード/デコード処理は手作業で作成することもできるし、過去はそうだった。
ただ、(>>725であげたような)問題があるから、最初は(日本語のような)自然言語で
メッセージの仕様(エンコードの規則)を記述していた。そして自然言語では、
仕様の曖昧さが残るから、形式的な仕様記述法が考案され、最終的にOSIプレゼンテーション層仕様の
一つとして、ASN.1(Abstract Syntax Notation：抽象構文記法)という名前で国際規格化された。
で、ASN.1の仕様策定と同時に、ASN.1で定義されたメッセージ仕様をエンコードするための規則も
策定された。これがBER(Basic Encoding Rule：基本エンコーディング規則)。
BERの中身は、階層的なType,Length,Value構造になっている。
自分としては、>>720で国際通信規格という言葉が提示されたから、
ああ、それは一般的なTLV構造ではなく、ASN.1/BERの事を指しているんだなと解釈し、
それ以降は>>720の意向に沿った形でレスしているつもりだよ。
0731720
2009/09/12(土) 02:14:31いや、全然沿ってない（w
どうも俺には ASN1 や XML ってパラノイア的に自由度
が高すぎるというか、レキシカルな部分とセマンティッ
クな部分がごっちゃになってるとういか、やれやれだぜ
とい印象を受ける。
TLV 的なもの、というのはレキシカルな意味で出したん
だよ。元々「シリアライズ」なんて言葉も出てたしオブ
ジェクトとの紐づけもそんなに難しくない。X というコ
ンポーネントがオプショナルに更に小さな a を持つ、
とかなら X の試験における a の有り無し評価くらいの
試験で済むじゃん。X が充分小さければ組合わせ数も
小さいし、X を含む試験では a の評価はオミット出来る。
ところが XML とかになるともう大変。あらゆる文脈で
X の a を評価しないといけなくなりそうなんだが皆どう
してんの? それとも皆そんなに巷のエンコーダ／デコー
ダ信用してんの?
俺が時流に乗ってないという意見は認める（w
0732デフォルトの名無しさん
2009/09/12(土) 02:58:30ではナゼ>>716でTLVを提案し、>>720で国際通信規格という言葉を持ち出したの？
そんな「パラノイア的に自由度が高すぎるというか....」な物を初心者に自慢したのはナゼ？
それを何度も問いているんだけど、まるで返答がない。まあ、どうでもいいんだけどね...。
>TLV 的なもの、というのはレキシカルな意味で出したんだよ。
TLVのレキシカル(lexical：字句)には、必ずシンタックス(syntax：構文)が伴う。
言語処理系を知っているなら、それは常識だよね。
そのTLV(BER)のシンタックスに対応するのがASN.1。
TLVという「パラノイア的に自由度が高すぎるというか....」な物を提案する以上、
そのシンタックスも一緒に考えないと、システム設計が崩壊するよ。
>皆どうしてんの? それとも皆そんなに巷のエンコーダ／デコーダ信用してんの?
今のネットあるいはビジネス分野では、SOAPやXML-RPCといったXMLベースの技術が主流だよ。
特にアプリケーションに近い開発者には、XMLとXMLスキーマは避けて通れない技術になりつつある。
ネットワークに近い開発者(たとえば、このスレ住人の大半であろうソケットプログラマ)であれば、
>>723の3番目にあげたProtocolBuffer/IDL/XDRが主流であると思う。ただし、実際の実装は、
手作業でデコーダ/エンコーダを作成することが大半。メッセージ形式が単純なうちは、それで十分。
もし、それが負担になるようなら、専用のコンパイラ(ソースコードジェネレータ)の導入を検討すべき。
ProtocolBuffer/IDL/XDRのどれもがプログラミング言語に近い様式でメッセージ形式を記述できるから、
多くのプログラマが活用できると思う。ただ、新しい技術の導入には、必ず壁がつきまとうから、
生産性や品質保証といった項目を十分に比較/検討してから、導入の是非を判断してください。
0733720
2009/09/12(土) 03:05:07> ではナゼ>>716でTLVを提案し、>>720で国際通信規格という言葉を持ち出したの？
TLV は国際通信規格でも使われてるし、もっとお手軽に
使える考え方でもあるでしょ。実際 >>710 だって独自に
> まぁ何送るか教えて、(サイズ教えて)、データ送るようにはしてた
って言ってるんだし。
そこに「そんなの教えてどうすんの」的なのを言いだす
方が「説教したいだけなんですね?」って思うけど。
0734デフォルトの名無しさん
2009/09/12(土) 04:11:50>TLV は国際通信規格でも使われてるし、もっとお手軽に
>使える考え方でもあるでしょ。
その「国際通信規格」という甘い言葉にのせられ、一見すると「もっともお手軽に使える考え方」に
思える「TLV方式の実体」というのが、ASN.1という「パラノイア的に自由度が高すぎる(>>731)」
枠組みで固めなければ容易に扱えない「怪物」であるという事を、気がついてくれないのかな....orz
>実際 >>710 だって独自に
>> まぁ何送るか教えて、(サイズ教えて)、データ送るようにはしてた
>って言ってるんだし。
>>710が言ったのは、単純に<長さ, 固定長ヘッダ(複数フィールド), 可変長ボディ(単一)>という
メッセージ形式ではないのかな。これはTLV方式じゃないよね。Typeフィールドが無いから。
このくらい単純なメッセージ形式であれば、(怪物である)TLV(あるいはXML)を採用しなくても、
ProtocolBuffer/IDL/XDRが使えるよ。どれも構造体/共用体/可変長文字列/可変長配列が定義できるし、
>>716にあった新旧バージョンの混在は、共用体で容易に実現できる。
返答してくれたから、>>720の意図は理解できた。説教臭いと感じているようだし、
後ろ向きな問いかけであるのは事実だから、これ以降は提案うんぬんの話は持ちかけない。
これで終わりにするよ。
0735デフォルトの名無しさん
2009/09/12(土) 09:01:200736デフォルトの名無しさん
2009/09/12(土) 11:48:28実際に受信してみればわかる
ioctlsocketとかでもわかるけど、それをやる前にザ・間違いリストの12番を読むべき
http://www.kt.rim.or.jp/~ksk/wskfaq-ja/articles/lame-list.html#item12
0737デフォルトの名無しさん
2009/09/12(土) 12:35:450738デフォルトの名無しさん
2009/09/12(土) 13:25:09元の質問は, 全部到着したかどうかを判定したいって書いてないんだが…
おれは, バッファをどれだけ増やせばいいかを調べるときには ioctlsocket
を使うけどな
0739デフォルトの名無しさん
2009/09/12(土) 15:41:51送信側は参加に関係ないのかな
0740デフォルトの名無しさん
2009/09/12(土) 17:18:10とっておきの解説サイトを教えてやろう。
http://www.google.com/
0741デフォルトの名無しさん
2009/09/12(土) 17:27:060742デフォルトの名無しさん
2009/09/12(土) 20:39:13くだらない。ひねりがない。
0743デフォルトの名無しさん
2009/09/12(土) 21:00:310744デフォルトの名無しさん
2009/09/12(土) 21:21:050745デフォルトの名無しさん
2009/09/12(土) 21:23:010746デフォルトの名無しさん
2009/09/12(土) 21:27:11>>739-740
次回用テンプレおいときますね
マルチキャストアドレスグループの参加の方法ってどうやるのでしょうか？
送信側は参加に関係ないのかな
とっておきの解説サイトを教えてやろう。
http://www.google.com/
0747デフォルトの名無しさん
2009/09/12(土) 21:36:490748デフォルトの名無しさん
2009/09/12(土) 21:39:350749デフォルトの名無しさん
2009/09/12(土) 22:09:23setsockopt で IP_ADD_MEMBERSHIP を設定するんじゃねぇの?
0750デフォルトの名無しさん
2009/09/12(土) 22:16:26・非ブロッキング
・acceptはSleepとセットのループ
・送受信はwrite(const void *p, int len)のようなラップ関数内で、recv/sendとselect（待つのは一つのソケットのみ）によるループ
により実装されていました。
※何れも一つのソケット（コネクション？）に対し一つのスレッドを生成し処理していました。
この場合、ブロッキングと比べてどのようなメリットがありますでしょうか？
私の無い頭だと、ブロッキングとあまり変わらないように思ってしまいまして・・・
0751デフォルトの名無しさん
2009/09/12(土) 22:59:49なにか質問があったら「ググレ」って得意げに言うのやめてもらえます？
こっちは別にあんたらみたいに教える気などなく説教したがりなだけの人に無理に聞こうと思ってませんよ。
私は、グーグルさんじゃなくて、ここで聞いているんです。
自分で調べる気がないのはなく、ここでもし知ってる人がいたら教えてもらおうという選択肢を選んだだけのこと。
教える気ないなら黙ってもらってて結構。
この掲示板の管理人さんに「質問はしないでください」といわれるのなら質問は自粛しますが
質問の制約のない掲示板で、管理人でもない分際の人に「自分で調べなさい」などと言われる筋合いはありません。
0752デフォルトの名無しさん
2009/09/12(土) 23:02:370753デフォルトの名無しさん
2009/09/12(土) 23:04:00バッファを動的に増減するメリットは何？
0754デフォルトの名無しさん
2009/09/12(土) 23:11:54「UDPで複数の端末にパケット投げたりできますか？」
という質問なら親切に答えたかもしれないけど。
0755デフォルトの名無しさん
2009/09/12(土) 23:21:460756デフォルトの名無しさん
2009/09/12(土) 23:28:25質問者に不快な思いをさせても回答者は損しない
従って回答者は何書いてもどうってことないが、質問者は書く内容をよく考えるべき
0757デフォルトの名無しさん
2009/09/12(土) 23:34:000758デフォルトの名無しさん
2009/09/12(土) 23:39:04最近いるようなのでもちつけ。
0759デフォルトの名無しさん
2009/09/12(土) 23:40:160760デフォルトの名無しさん
2009/09/12(土) 23:40:530761デフォルトの名無しさん
2009/09/12(土) 23:41:060762デフォルトの名無しさん
2009/09/12(土) 23:41:530763デフォルトの名無しさん
2009/09/12(土) 23:42:03ブロックするか、ブロックしないか
0764デフォルトの名無しさん
2009/09/12(土) 23:49:44=== マルチスレッド＆ブロッキング方式 ====
<利点>
・プログラムのロジックが単純になる。一般的なCプログラムが標準入力からのreadと
標準出力へのwriteをループさせて処理しているように、ソケットとのreceive/sendを
ループさせることで処理を実現できる。
・上記の理由により、TCPはレコード境界が無いプロトコルであるにもかかわらず、
receiveで待ち続ければいいから、受信メッセージの組立て処理のロジックは単純になる。
・マルチコア/マルチプロセッサ構成ではスレッド単位にコアまたはCPUが割り当てられるから、
コア数/プロセッサ数に応じてシステムの性能がスケーラブルに向上しやすい。
<欠点>
・スレッド間で資源の競合がある場合(たとえば同じ変数/ファイルを複数のスレッドが共有する場合)、
スレッド間で排他制御が必要になる。一般に、排他制御のデバッグは再現性が無いために難しい。
=== シングルスレッド＆非ブロッキング方式 ====
<利点>
・そもそもスレッド間の資源競合が存在しないため、デバッグが容易になる。
<欠点>
・プログラムのロジックが複雑になる。TCPコネクション単位にオブジェクトを管理する(Cであれば、
たとえば構造体で送受信バッファ等を表現し、それらをリンクリストで繋いで管理する)必要がある。
・TCPはレコード境界の無いプロトコルであるため、ソケットに届いた受信メッセージの断片を
少しずつ組立て、さらにその処理を各TCPコネクション上で並行に実行させる必要があるため、
プログラムのロジックが複雑になる。
・マルチコア/マルチプロセッサ構成ではコアまたはCPUへの割り当てはコンパイラの最適化に
依存するから、コア数/プロセッサ数を増やしていっても、期待したほどシステムの性能は向上しない。
他にもあれば(訂正を含めて)追加ヨロ >>all
0765デフォルトの名無しさん
2009/09/13(日) 00:02:20プロセス間通信をしたいんですけど、
サーバーは同一のパソコン上で一つのみしか
起動できないんでしょうか？
複数サーバーがあるとクライアントがどのサーバーにつなげば良いのかわからないのでは？
と思うのですが。
それとも、サーバーのアドレスはそれぞれ異なるように設定できて
そういう問題は起こらないんでしょうか？
よろしくお願いします。
0766デフォルトの名無しさん
2009/09/13(日) 00:07:43クズ質問者に文句付けるのがオレの流儀。
管理人に「クズ質問者に文句付けるな」と言われたら自粛するが、
制約の無い掲示板で、管理人でも無い分際のクズに「ググれ言うな」と
言われる筋合いは無い。
嫌なら来るな。
0767本当に”管理”者です
2009/09/13(日) 00:10:54ググれ言うな。
0768デフォルトの名無しさん
2009/09/13(日) 00:14:05ポート番号というもので区別できるようになっている
サーバの待機するポート番号とクライアントの接続先のポート番号が一致したものが接続される
HTTPは80番、FTPは21番、のように、サーバの種類ごとにあらかじめ決まっている
同じポート番号でサーバを2つ起動することは出来ないので、その場合は番号をずらすなりなんなり調整する
0769デフォルトの名無しさん
2009/09/13(日) 00:14:46消えろ。カス。
0770デフォルトの名無しさん
2009/09/13(日) 00:16:12ごく稀なケースだけど, 俺は,
各データのサイズが結構巨大な可変長のデータで頭にデータ長がない
場合に使う
0771デフォルトの名無しさん
2009/09/13(日) 00:16:44なるほどー。ポート番号で区別するんですね。
設定の仕方とか調べてみます。
0772デフォルトの名無しさん
2009/09/13(日) 00:23:39それすると何が嬉しいんだ? パフォーマンスには影響無さそうに思う。
0773デフォルトの名無しさん
2009/09/13(日) 00:24:430774デフォルトの名無しさん
2009/09/13(日) 00:26:120775デフォルトの名無しさん
2009/09/13(日) 00:26:130776デフォルトの名無しさん
2009/09/13(日) 00:32:38何とsocketのポート番号との違いを知りたいの？
0777デフォルトの名無しさん
2009/09/13(日) 00:37:570778デフォルトの名無しさん
2009/09/13(日) 00:50:42mallocして一回?のrecvで受信するのと固定長バッファで複数回recvするのと
どちらが効率が良いかって話になりますね。
固定長バッファのサイズにもよるけど>>772さんの言われるようにたいして
パフォーマンスは変わらない気がする。
0779デフォルトの名無しさん
2009/09/13(日) 00:54:16socketにポート番号はない。
ポート番号はUDPやTCPに対してある。
0780デフォルトの名無しさん
2009/09/13(日) 01:54:14おぉありがとうございます。
でもこのアプリはマルチスレッド＆非ブロッキングなんですよ。
一つのスレッドは一つのソケットしか操作しないのでブロッキングでもいいような気がするんですが。
メリットがあるとすれば、スレッド（送受信）の停止等を楽にコントロール出来るってところでしょうか？
っと思いましたがSleepやselectでの待機処理があるので一緒な気もします。
しかし本当の意味?での非ブロッキングはすごく複雑そうですね・・・
0781デフォルトの名無しさん
2009/09/13(日) 04:02:41一回は無理してでもシングルスレッドで書いとくと
後の人生で応用が利くからお勧め
0782デフォルトの名無しさん
2009/09/13(日) 05:25:360783デフォルトの名無しさん
2009/09/13(日) 09:28:28selectはコネクション数が非常に多い場合に非効率的になる。
>>782
UDPやTCPはプロトコルです、socketではありません。
0784デフォルトの名無しさん
2009/09/13(日) 18:45:45thx!
0785デフォルトの名無しさん
2009/09/13(日) 18:50:10１万個くらいつくれるの？
0786デフォルトの名無しさん
2009/09/13(日) 19:27:46他にも制限あるだろうけどね。
0787764
2009/09/13(日) 19:28:48>でもこのアプリはマルチスレッド＆非ブロッキングなんですよ。
>>764に挙げたのはselectによるタイマ監視を使用しない、一般的なケースですね。
もし>>750のようにタイマ監視が前提であれば、receiveによるプロセスのブロックは
selectによる監視の妨げになりますから、非ブロッキングなreceiveを使います。
ソケットは1個でも、そのデータ受信イベントとタイムアウト発生イベントを
同時に待ち受けるわけですから、selectの利用は自然な発想だと思います。
あと>>750で気になったのは、acceptをSleepとのループで待っているとの記述です。
acceptも(receiveと同じように)TCPコネクション確立通知イベント発生をタイムアウト付きで
selectを用いて監視できます。Sleepというのが何なのか分かりませんが(おそらくは独自の
マクロかライブラリ関数？)、C標準ライブラリのsleep関数に相当ものであると仮定すれば、
sleepによる待ち時間は無駄ですから、TCPコネクション確立通知に対する応答時間を
遅延させるだけの意味しか持たないように思えます。だから一般的にはタイムアウト付きの
selectでacceptをループさせます。謎のSleepについて、調査する必要があるかもしれません。
(長いので続く)
0788764
2009/09/13(日) 19:34:47>しかし本当の意味?での非ブロッキングはすごく複雑そうですね・・・
非ブロッキング処理を一般的に書くと>>764のようになって難解に見えますが、
その実装方法は「イベント駆動プログラミング」です。GUIアプリ開発では一般的ですよね。
普通の対話型Cプログラムだとscanf/printfのループで処理しますが、イベント駆動なGUIだと、
まずイベント待ちループに入り、マウスクリック/キー押下イベントが発生すると、事前に
登録しておいたアクションが実行され、そのアクションの中でウィジェットを操作します。
ネットワークプログラムにおけるイベント駆動プログラミングも同様に、イベント待ちループ内の
selectでTCPコネクション確立通知/データ受信(複数)/タイムアウトといったイベントの発生を
同時に待ち受け、イベントが発生すると対応するアクションを実行し、そのアクションの中で
独自プロトコルを実装した有限状態機械(Finite State Machine)へ発生イベントを送ります。
何度か開発経験を重ね、慣れてくるとイベント駆動処理を独自のライブラリ関数として
設計できるようになると思います。またGUIアプリ開発でも考え方は同じですから、
その本質を理解できれば、Webブラウザやメーラのようなネットワーク対応GUIアプリも、
自分で一から開発できるようになる訳で、(>>781が言うように)後の人生で応用が利きます。
大変ですが技術の習得をお勧めします。
0789デフォルトの名無しさん
2009/09/13(日) 19:37:05Sleep(0)を呼び出しているんじゃないのか？
Sleepに与えている時間は何ミリ秒なんだ？>>780
0790デフォルトの名無しさん
2009/09/13(日) 20:29:14サーバもクライアントも自作なのでなんでもし放題です
0791デフォルトの名無しさん
2009/09/13(日) 20:42:54ipsecとか、ssh port forwardとか。
0792デフォルトの名無しさん
2009/09/14(月) 00:00:25レスありがとうございます。
同期recvのみでもデータ受信とタイムアウト発生を待機出来るような気がしますが、
やはりselectの方が良いのでしょうか？
sleepは>>789さんの仰る通り、Win32APIのSleepを呼び出しているようです。
接続が無い場合の無駄なループを減らすためか、100ms待機しています。
しかし>>787さんのselectを使う方が理にかなっていますね。
あと勘違いしてましたが、acceptの場合は非ブロッキングやselectのメリットって多いんですね。
というか同期acceptのみだと、停止（やるとすると無理矢理かWSACancelBlockingCallかな？）や受け入れ数制限とか出来ないんですね。
>>788
おかげさまで少しだけイメージが掴めてきたような気がします。
でもブロッキングに比べて、スレッドやメモリは節約できますが、コアが多くなるほど全体的なパフォーマンスが落ちるような気もします。
その場合はある程度接続が多くなると、スレッドを増やす感じなのかな？（イベントオブジェクトの場合は必然的にそういう実装になるようですが）
おもーい腰を上げて、もう少し他のP2Pあたりのソースコードでも読みつつ勉強しようと思います。。
■ このスレッドは過去ログ倉庫に格納されています