ネットワークプログラミング相談室 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/
0666デフォルトの名無しさん
2009/09/08(火) 01:22:010667デフォルトの名無しさん
2009/09/08(火) 01:28:56そのあたりの面倒を全部引き受けてくれるのがTCP
パケットの順序がバラバラになっても一部が失われても再送したりして復元してくれるし
相手が忙しそうなら送信スピードを自動的に調節したりもする
UDPはパケットが失われたり順序が入れ替わったり同じパケットが2度届いたり
等の現象にすべて自分で対処しなければならない
>>665
TCPは複数のsendを1つのパケットにまとめて転送効率を上げたり
送信スピードを調節してゆっくり送ったりする機能があるので
sendした分が実際に送られるパケットサイズと一致するとはまったく限らないし
sendしたバイト数とrecvできるバイト数が一致するなどとはまったく期待できない
recvは1バイトでも今すぐ返せるデータがあればさっさと返すような仕様になってるから、そういう動作をする
例えばGIFのインタレース表示をしたいブラウザなんかは、一部でもデータが到着したら
その部分はもう描画し始めたいわけだから、そういう仕様でないと困る
固定サイズずつ処理したいアプリケーションは、そのサイズが来るまで繰り返しrecvを呼べばよい
0668デフォルトの名無しさん
2009/09/08(火) 01:50:54たとえばだな、イーサネットのフレームサイズは 1500 バイト程度だ
IPが連続したデータとして、ある程度はめんどう見てくれるけど
UDP には到達保証を行う機能がないので 10k 送った中で 1 フレーム
でもエラーを起こすと 10K 全部が全滅
0669デフォルトの名無しさん
2009/09/08(火) 07:14:16ネットワークプログラミングってこの話題しかないし
この話題には回答者がいっぱい出てくるねｗ
0670デフォルトの名無しさん
2009/09/08(火) 08:04:58どんな感じになるのでしょうか？
TCPならコネクション切断されるまでが一つのデータ？
UDPならその境目がないような
0671デフォルトの名無しさん
2009/09/08(火) 08:12:45だったら簡単だろ。
0672デフォルトの名無しさん
2009/09/08(火) 08:13:160673デフォルトの名無しさん
2009/09/08(火) 08:33:50このデータが来たら一つのデータ終わりとか
0674デフォルトの名無しさん
2009/09/08(火) 08:50:45通信先分ソケットを作るのではどっちが効率いいんだろう
必要分のバッファをソケットに確保しておけば変わらない？
0675デフォルトの名無しさん
2009/09/08(火) 12:27:18一つのスレッドが一つのソケットで通信するようにして、
ソフトウェアスレッドをハードウェアスレッド数作成するのが一番いい。
0676デフォルトの名無しさん
2009/09/08(火) 13:02:490677デフォルトの名無しさん
2009/09/08(火) 13:03:380678デフォルトの名無しさん
2009/09/08(火) 19:30:32・ひとつのソケット
・通信先の数のソケット
どっちがいい？ってことだから間違ってはないんじゃないの？>>675-676
0679デフォルトの名無しさん
2009/09/08(火) 19:33:470680デフォルトの名無しさん
2009/09/08(火) 19:54:570681デフォルトの名無しさん
2009/09/08(火) 20:45:25こいつは頭がいかれているのか、それとも何か方法があるのか
0682デフォルトの名無しさん
2009/09/08(火) 20:50:260683デフォルトの名無しさん
2009/09/08(火) 20:50:470684デフォルトの名無しさん
2009/09/08(火) 20:55:44上司か？ｗ
さらに上に相談して解雇してもらえｗ
0685デフォルトの名無しさん
2009/09/08(火) 20:57:030686デフォルトの名無しさん
2009/09/08(火) 21:00:07ローカルにキャッシュ置いといたりするのはよくやるけど。
あと、接続に失敗したらsleepして、ネットワークが回復したら再トライとか。
0687デフォルトの名無しさん
2009/09/08(火) 21:00:370688デフォルトの名無しさん
2009/09/08(火) 21:01:310689デフォルトの名無しさん
2009/09/08(火) 21:05:51あらかじめクライアント側に自動的にあらゆるデータを改ざんするプログラムを仕込んでおけばおｋ
0690デフォルトの名無しさん
2009/09/08(火) 23:00:56プログラムが固まってしまうとかはNG
0691デフォルトの名無しさん
2009/09/09(水) 00:47:06それらを一つのデータとしてバッファに入れる方法ってあるのでしょうか？
recvで一度に受信できるサイズを1パケット以下にすればいいのでしょうか？
0692デフォルトの名無しさん
2009/09/09(水) 00:50:13recv1→recv2 もしくは、recv2→recv1 の順番に処理されますよね
それを、recv1→ と同時に処理させることは可能なのでしょうか？
recv2→
前者だと見かけ上は、同時にやろうとしてるけど、順番で処理していくのですが
後者だと処理速度は半分程に落ちるけど同タイミングにきても同じスピードで処理していくみたいに
これって、プログラムだけで組めますか？
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プロセス間通信をしたいんですけど、
サーバーは同一のパソコン上で一つのみしか
起動できないんでしょうか？
複数サーバーがあるとクライアントがどのサーバーにつなげば良いのかわからないのでは？
と思うのですが。
それとも、サーバーのアドレスはそれぞれ異なるように設定できて
そういう問題は起こらないんでしょうか？
よろしくお願いします。
■ このスレッドは過去ログ倉庫に格納されています