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

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

レス数が900を超えています。1000を超えると表示できなくなるよ。
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/
0809デフォルトの名無しさん2010/10/12(火) 22:44:56
>>808 すまん黒猫の意味がわからん、教えてたもれ？？？
0810デフォルトの名無しさん2010/10/12(火) 22:53:05
MMOの小規模な奴を作ってみようと思うんだが

クライアントはC、C++で作って
サーバーをどうするか悩んでる

OSはWindowsサーバーかLinuxか

多数接続する場合、ソケット1つにつき、スレッド１つ割り当てるか
Selectで一つづつ見ていく処理にするか

あまり高速な処理が要求される内容じゃないんだが
助言求む
0811デフォルトの名無しさん2010/10/12(火) 22:56:45
各プラットフォームで最速な奴を使うべきだろ。
IOCP/epoll/kqueueとかその辺。
0812デフォルトの名無しさん2010/10/12(火) 23:01:29
linuxには詳しくなかったからその辺勉強してみます
サンクス
0813デフォルトの名無しさん2010/10/12(火) 23:22:09
>>810
もし「Linux＆小規模＆高速性は要求されない」のであれば、
マスタ・スレーブ方式のマルチプロセス構成でサーバを設計するのが、最も単純。
言い換えると、ソケット1つにつき、1つのプロセス(スレーブ)を割り当てる方式。
具体的には、Linux標準サーバのftpdやtelnetdがこの方式で実装されている。

各スレーブには独立した仮想メモリ空間が割り当てられているから、
スレッド方式と比較して安全な設計が可能だし、シングルプロセス＆select方式と比較すれば
イベント駆動制御も不要だから楽に設計できるし、デバッグも簡単といった利点がある。
欠点はLinux(UNIX)依存であることと、大規模＆高速性が他と比較して劣る事。

動作を簡単に解説すると、マスタプロセスがacceptで接続通知を待ち受け、
スレーブプロセスをfork&execする、というもの。(ApacheのCGIと同じ、と考えれば分かりやすい鴨)
あと、マスタプロセスは自分で開発しなくても、inetd(インターネットスーパーデーモン)に
接続待ち受け＆スレーブ生成をまかせ、スレーブだけをC/C++等で実装することも、場合によっては可能。

UNIXでは古典的な方式で、例題も豊富に有るから、最終的にどの方式を選択するかとは別に、
一度勉強しておくことを勧める。将来、きっと役に立つはず。
教科書なら、このスレの図書コーナー(>>2)にある
・UNIXネットワークプログラミング〈Vol.1〉ネットワークAPI:ソケットとXTI
・TCP/IPによるネットワーク構築〈Vol.3〉クライアント‐サーバプログラミングとアプリケーション
あたりがバイブル的な存在で、個人的なお勧めかな。
0814デフォルトの名無しさん2010/10/12(火) 23:39:10
サーバーには玄箱を使おうと思うんだが

無謀かな？

PowrePC　233M

無謀だわな・・

ゲーム内容はWIZのオンラインみたいなのを考えてるから
リアルタイム性はそんなに高くない

けど・・

玄箱じゃ無謀だわな
0815デフォルトの名無しさん2010/10/12(火) 23:50:02
同時20人くらいならそのくらいのスペックでOKだったよ
コントロールやチャット程度ならね
画像もあると、ちと苦しい
0816デフォルトの名無しさん2010/10/13(水) 00:05:26
PPC/233ってことは初代の玄箱で、あれってメモリが64MBしか搭載されていないよね。
そうであれば、

>多数接続する場合、ソケット1つにつき、スレッド１つ割り当てるか
>Selectで一つづつ見ていく処理にするか

のどちらか(= シングルプロセス構成)にしないと厳しいだろね。

それでも、ゲーム内容にもよるが、同時100TCPコネクション程度は耐えられるんじゃないかと思う。
もちろんメモリがキツキツだから、LinuxをDebian(Sarge?)に入れ換えて、
カーネル再構築や不要なデーモン停止といった、チューニング(スリム化)作業必須が大前提になるけど。

自分なら、安い中古ノートPC(Cell/700Mhzクラス)にメモリ512MBくらい入れて、>>813の
マルチプロセス構成にするんだけどね。まぁ検討しているうちが最も楽しいから、色々考えてみるが良し。
0817デフォルトの名無しさん2010/10/13(水) 00:06:29
>>813
クライアント同士でのデータのやりとりが多発するMMOでクライアントごとにプロセスはないだろ・・・
0818デフォルトの名無しさん2010/10/13(水) 00:16:25
>>817
まったくだ >>813 のド素人振りがよくわかるレスだよな
0819デフォルトの名無しさん2010/10/13(水) 00:18:13
>>814
そのスペックあれば, ネットワークのレイテンシーさえビハインド出来れば問題ないよ
動的生生成ページでを秒あたり100程度のトランザクションは何とかなる
ただし, いかに2次記憶を動かさないかが腕のみせどころになるが………
0820デフォルトの名無しさん2010/10/13(水) 00:19:44
全部UDPでやったろうか

パケット紛失しまくり
0821デフォルトの名無しさん2010/10/13(水) 00:20:50
>>818　ならどういう設計がいいんだ？
0822デフォルトの名無しさん2010/10/13(水) 00:23:50
いまゲームのロゴ用フォント作ってる
タイトルはWearezardryにしたい

フォント作り難しい・・・
0823デフォルトの名無しさん2010/10/13(水) 00:48:41
しーん
0824デフォルトの名無しさん2010/10/13(水) 03:19:37
>>810
クライアントのターゲットがWindowsなら、サーバーもWindowsにしておいた方が
コードを共有できる部分も増えてらくなのではないかと思う。
Windows Direct Accessとか使うと、楽できるかもしれないし。

クライアントの数が数百とかになるなら、
クライアント毎にスレッドを起こしていたらサーバーが持たない。

>>820
リアルタイム性の高いゲームならUDPもあり。
TCPで再送している間に遅延が起こるくらいなら、UDPで遅延したデータは捨てる。
0825デフォルトの名無しさん2010/10/13(水) 04:35:40
>>817
いや、「単純」という文脈であれば間違ってないよ。

「スケーラビリティ」とかって単語が出てくるようであれば、
言語云々は別として、ステートマシンしかないけど。

Pythonが書けるなら、twistedをおすすめするのだが…
0826デフォルトの名無しさん2010/10/13(水) 09:05:04
Wearezadryのロゴできたーうぉー
慣れないInkscapeと一晩格闘してやっとこできた・・
普段絵なんぞ触らんからスゲー時間かかったわ

どう？それっぽいかな？

http://uproda11.2ch-library.com/268426saK/11268426.gif
0827デフォルトの名無しさん2010/10/13(水) 10:06:53
>>825
ねーよ
0828デフォルトの名無しさん2010/10/13(水) 10:59:07
>>825
言語としてPythonはねーわ・・・
0829デフォルトの名無しさん2010/10/13(水) 11:07:59
>>825
fork方式でプロセスわけちゃうとスレーブ同士のIPC通信が必要になるケースなんだから
全然「単純」にはならんのじゃまいか？

それとtwistedって並み居る非同期フレームワークの中で、何がいいの？
今だとnode.jsとかも流行りだけどさ
Pythonでもeventletなら、コルーチン＋モンキーパッチを利用して
非同期特有のコールバックでなく、同期のソケットとと全く同じpull型の
記述が出来るので、FSM書き下すより楽ですよって主張と受け取れるんだけどさ
eventletみたいなのは、さすがに動的言語でないと無理だなあと思う
ゲームでコルーチン使いたくてスクリプティングにluaとかが使われるのと同じだよね

なんか思いつきで適当なことホザいてるようにしか見えない
0830デフォルトの名無しさん2010/10/13(水) 11:16:27
forkフルボッコでわらた
0831デフォルトの名無しさん2010/10/13(水) 12:17:03
> それとtwistedって並み居る非同期フレームワークの中で、何がいいの？
楽なのはlibeventを使う方法
パフォーマンスも悪くない
0832デフォルトの名無しさん2010/10/13(水) 12:40:38
>>831
いやそういうことじゃなくて
何でtwistedなんか薦めるの？という突っ込みだったんだが…

まあいいか（どうでも）
0833デフォルトの名無しさん2010/10/13(水) 14:09:10
>>832
知るかボケ >>825 にレスしろよ
0834デフォルトの名無しさん2010/10/13(水) 14:21:30
>>833
は？
>>831が俺(>>829)に（的外れな）レスをつけてるみたいだから答えただけなんだが？
0835デフォルトの名無しさん2010/10/13(水) 14:26:29
>>834 = >>832 = >>829 かよｗ
どれも馬鹿まるだしのレスだなw
0836デフォルトの名無しさん2010/10/13(水) 18:25:53
python って asyncore で間に合っちゃうよね
twisted に拘るメリットって何があるのか教えて欲しい
(煽りじゃなくてマジで)
0837デフォルトの名無しさん2010/10/13(水) 20:01:26
今理解できてるものでやれ
何をデバグしてるのかわからなくなるぞｗ
0838デフォルトの名無しさん2010/10/13(水) 20:05:51
>>826
剣が鉛筆みたいだ、そこいじればカコイイ
0839デフォルトの名無しさん2010/10/14(木) 00:00:43
eventletもそれなりに重いがtwistedは選択技にすら上がらねー
0840デフォルトの名無しさん2010/10/14(木) 00:12:53
なんでerlangが出てこないんだ
0841デフォルトの名無しさん2010/10/14(木) 11:37:28
>>840
選択肢としてふさわしくないからでしょう。
0842デフォルトの名無しさん2010/10/19(火) 06:16:18
Windows環境のJavaのソケット通信で質問させてください。

ソケット常時接続で通信を行うサーバ・クライアントモデルの
クライアント側アプリケーションを作っています。

OSはWindow 2003、JavaはJDK6を使用しています。

クライアント - サーバ間は、
[クライアント] - [スイッチングハブ] - [ルータ] - [サーバ]
という構成になっています。

クライアント側からアクティブオープンでソケット接続後、
常時read用スレッドおよび、write用スレッドの２つの非同期
スレッドでソケットを共有して使用しています。

ここで [スイッチングハブ] - [ルータ] 間のLANケーブルを
抜き、しばらくするとクライアントのread処理で例外
「SQLException(connection reseted)」が発生します。
08438422010/10/19(火) 06:19:50
Wiresharkで確認してみたところ、LAN線を抜いた後の
write処理でTCP PSHのリトライを繰り返しており、
リトライを7〜8回繰り返した後に、上記の例外が
出力されます。

このとき、クライアント側からFINもRSTも出力されていません。
クライアント側の実装で、shutdownもcloseもしていませんでした。

別途クライアントをJavaのプログラムからWinsock2.0を使用した
ツール(SocketDebugger)を使用してサーバに接続し、LAN線を
抜いた後にツールからデータ送信(write)を行ったところ、
Wiresharkのログは上記と同じものが出力され、ツールには
WSAECONNABORTED(10053)が発生したと出力されました。

WinsockがTCP PSHのリトライオーバによりソケットを
破棄したものと思われるのですが、このソケットの破棄が
行なわれないようにすることは可能でしょうか？
可能な場合、どのようにすればよいか、ご教示願います。

上記現象でソケット破棄されることがWinsockの仕様(避けられない)
場合、TCPのリトライ回数やリトライ間隔(時間)を増やすことは
可能でしょうか？

以上、よろしくお願いします。
0844デフォルトの名無しさん2010/10/19(火) 10:34:41
頑張ってる様子が伺えるが、混乱してるよ。例えば

・「SQLException」->SQL使ってんのか。通信の上にいろんなのかぶりすぎでは
エスパー以外わからんよ。
・「ソケットを破棄したものと思われる」->「思われる」じゃだめだろ。
ここが発端で「ソケット破棄を防ぐには〜」とおかしな方向に行ってる。

察するところ
TCP接続が切れてもアプリとしては何事もなかったように通信を続けたいのか？
それなら、エラーを適切に判断して適切に再接続して元の処理に戻るだけ。

（俺が作るなら関数コールでの制御じゃなくて状態変数を使って制御するが
それはまあ別の話）

アドバイス：
いきなり難しいことをやろうとして技術が追いついてないっぽいががんばれ。
自分が作ろうとしてるものをちゃんとレイヤ化して考えといい。
エラー発生箇所をもっと（OSのAPIまで）絞り込むくせをつけるといい。
0845デフォルトの名無しさん2010/10/19(火) 10:39:40
一時的にケーブルが引っこ抜けたとしてもTCPのコネクションは切断したくないって話じゃないかなぁ
0846デフォルトの名無しさん2010/10/19(火) 10:39:45
大事なこと削っちゃった。

ソケットは「破棄」されてないと思うぞ。
0847デフォルトの名無しさん2010/10/19(火) 10:53:52
>>845 それなら、
・接続時にキープコネクションを有効にせず
・切れてる間に一切通信しようとしなかった
なら可だが、それ以外なら無理ジャネーノ。

まずは本人が何をやりたいのかだな
0848842,8432010/10/20(水) 03:57:56
みなさん、回答ありがとうございます。
つたない内容の文章を読んでいただき恐縮です。

>> 844 さん
「SQLException」は、「SocketException」の誤りでした。
　申し訳ありませんでした。

> 察するところ
> TCP接続が切れてもアプリとしては何事もなかったように通信を続けたいのか？

　ご指摘の件ですが、私個人としては「例外を検知したので、
　ソケットの再接続を行う」という実装にしたい(している)のですが、
　サーバ側のアプリ開発の方から、
　「経路のチェックは、アプリレベルのヘルスチェック送受信の
　　タイマーでのみ管理すべきであり、それ以外の制御下でソケットを
　　切断することは、基本認められない」と言われており、

　>> 845 さんが言われました、
　> 一時的にケーブルが引っこ抜けたとしてもTCPのコネクションは
> 切断したくないって話じゃないかなぁ

を実現する方法がないかを模索しているところです。

＃ アプリレベルのヘルスチェックについて、前回説明しておりませんでした。
　　申し訳ありません。
0849842,8432010/10/20(水) 04:36:44
＃ またヘルスチェックのほかに、アプリレベルで電文の
　送達管理(電文送信時、相手から電文受信電文が送付される)
も行っております。

さらにサーバ側アプリ開発者からは、
「Javaで実装しても、LANケーブル断線時にソケットが
勝手に切断されることはないはず」
ということを言われ、できる術を探しているところです。

＃ サーバ側開発者の方に対策方法を聞ければよいのですが、
　 立場的に聞けない関係なのです・・・。

現状、調査があいまいな状況なのですが、私見では
>>847 さんが言われた
> ・接続時にキープコネクションを有効にせず
> ・切れてる間に一切通信しようとしなかった
> なら可だが、それ以外なら無理ジャネーノ。

ではないかと思っております。

いずれにしても、>>845 さんからもアドバイス
いただいたとおり、もう少し深く調査し、原因を
絞り込んでみます。
0850デフォルトの名無しさん2010/10/20(水) 05:32:37
宿題は宿題スレへ
0851デフォルトの名無しさん2010/10/20(水) 09:07:41
>>849
原因と言うか、送信タイムアウトでソケットが切断されるのはTCPの仕様なので、
その要求を満たそうとするなら必然的にTCPを使用しないと言う選択肢しかないと思うよ。

通信経路のヘルスチェックが、厳密にはソケット自身でしか出来ないですしね。
間に介在しているすべてのルーターやHUB、プロキシをクライアント側の
ヘルスチェックでどうこうできるものでもないし。

とりあえず、その要求仕様を突き付けている馬鹿に、サンプルプログラムでも
書いてもらうしかないじゃない？
0852デフォルトの名無しさん2010/10/20(水) 09:18:20
その要求仕様を突き付けている馬鹿は >>849 自身のことだろ

だから

>＃ サーバ側開発者の方に対策方法を聞ければよいのですが、
>　 立場的に聞けない関係なのです・・・。

こんなことになってんだよw
0853デフォルトの名無しさん2010/10/20(水) 13:29:14
サーバ屋さんが言ってるのが正しく、切断はされないと思う。
ケーブル抜いてタイムアウトしたら、writeかreadでEWOULDBLOCKが返ってこないか?

ただし、期間が余り長いとDHCPのリース期間終了とか他の要因で切断はある。
0854デフォルトの名無しさん2010/10/20(水) 14:10:38
>>842
こんなのあった。
http://support.microsoft.com/kb/931319/
0855 ◆0uxK91AxII 2010/10/20(水) 18:41:24
Windows で TCP/IP のメディア検出機能を無効にする方法
http://support.microsoft.com/kb/239924/

んゆ。
0856デフォルトの名無しさん2010/10/20(水) 19:12:09
>>855
無効にならねーよバカ
0857デフォルトの名無しさん2010/10/21(木) 00:43:29
メディア検出は、サーバPCもクライアントPCも有効のままだよね。
PCが直接つながってる線のリンクはダウンしないって話でしょ。



手元の資料によるとPosix.1gのTCPソケットオプションで
TCP_MAXRT っていうのがあって、
「TCPがデータの再送を開始してからコネクションが切断されるまでの
時間を指定する。値にゼロを指定するとシステムのデフォルト値を用いる
ことを意味し、-1を指定すると永久に再送を行うことを意味する。…」

とある。けど、Windows2003についてくるWinsockのTCP実装が
TCP_MAXRTを実装しているかは未調査。あと、Javaで指定できるかも
微妙。

ttp://download-llnw.oracle.com/javase/1.4.2/docs/guide/net/socketOpt.html
には載ってない。
08588422010/10/21(木) 08:08:33
>>851 さん
その後、サーバ側のアプリ実装者からソケットの実装処理を
抜粋し、紙で提供していただく機会があったのですが、
java.net.Socketを使用した一般的な実装で、特別なソケット
オプション指定やロジックを使用しているようには見えない
ものでした。

その実装で、問題（TCP自動切断）が発生したことがないと
言われており、ますます混乱しているところです・・・。
（その方の実行環境は、WindowsXP SP3だそうです。）


>>852 さん
私がその立場にいたのでしたら、「すいません」と言って
仕様変更するという調整もできたかもしれないのですが・・・（；_；）
08598422010/10/21(木) 08:12:51
>>853-857
情報提供ありがとうございます。
現在行っている調査の参考にさせていただきます。

＃ 進展のない話を書いてもスレ汚しですね。
　　調査結果がなんらか出てから書き込むようにします。
0860デフォルトの名無しさん2010/10/21(木) 19:39:47
Windows
http://support.microsoft.com/kb/158474
MaxConnectRetries
MaxDataRetries
Linuxなら
tcp_retries1,tcp_retries2とか？
0861デフォルトの名無しさん2010/10/22(金) 19:57:54
リトライ回数=無限を設定できない限り解決にならないし
大きな値を設定したとしてもリトライ間隔がえらいことになるぞ
（リトライ毎にタイムアウト時間が倍々になったり。。。）
ワケの分からないことは止めて普通に再接続処理しなきゃダメだよ
0862デフォルトの名無しさん2010/10/23(土) 16:29:22
winsockで質問です。
相手から送られてくる文字列って何バイトか分からないと思うんです。
なので、あらかじめ文字列バッファを適当に確保しとくしかないと思うんですが、
なんとか送ってきたデータのサイズをチェックして動的確保したバッファにrecvできるような
方法ないですか？
0863デフォルトの名無しさん2010/10/23(土) 16:41:58
それを書くのがプログラマの仕事だ
0864デフォルトの名無しさん2010/10/23(土) 16:43:23
わかったよ
0865デフォルトの名無しさん2010/10/23(土) 21:12:46
>>862
最初にバイト数を書いといてもらう
で、バイト数が書いてある所だけ読んで確保する
0866デフォルトの名無しさん2010/10/23(土) 22:28:35
>>865
素晴らしい発想ですね。ありがとうございます。
0867デフォルトの名無しさん2010/10/24(日) 00:48:57
つ[車輪の再発明]
HTTPって本当に良く考えてるなと思うわ
0868デフォルトの名無しさん2010/10/24(日) 01:11:57
俺は学校で行なわれている教育を車輪の再発明とは表現しないが、する人もいるのかな？
0869デフォルトの名無しさん2010/10/24(日) 09:15:40
>>867
なぜそこでHTTP・・・
ストリームもので必ずついて回る問題だから
車種も無限にあるし、車輪は無限にあるよ
0870デフォルトの名無しさん2010/10/24(日) 09:32:27
HTTPは>>862の要望にはそぐわないけどな。
ヘッダサイズが不明だから。
0871デフォルトの名無しさん2010/10/24(日) 09:32:54
「車輪の再発明」と言い出す奴は「私バカです」と言っていると思っても、99%までは間違いない。
0872デフォルトの名無しさん2010/10/24(日) 11:20:49
>>868
ここは学校じゃないぞ？宿題スレでもないし
0873デフォルトの名無しさん2010/10/24(日) 11:41:12
MacBinary は偉大だったというオチ
0874デフォルトの名無しさん2010/10/24(日) 12:08:33
>>869
でも解決策は無限にないよね
どれもこれも似たような解決策ばっかり
まあ、ひねったプロトコル書かれても面倒くさいだけなんだが
0875デフォルトの名無しさん2010/10/24(日) 12:13:21
すごく重要なサーバーを書く場合はやっぱりCが一番かな
C#とかJavaは危険かな
0876デフォルトの名無しさん2010/10/24(日) 12:17:20
危険ねえ
0877デフォルトの名無しさん2010/10/24(日) 12:34:41
危険か安全かならＣの方が危険だと思う。
0878デフォルトの名無しさん2010/10/24(日) 13:08:44
危険って言ってる奴がCでsegmentation faultとかの例外も書かないのが世の常
0879デフォルトの名無しさん2010/10/24(日) 13:10:19
書くとろくなコードが生まれないからそのままでおk
0880デフォルトの名無しさん2010/10/24(日) 13:10:31
例外が出るほうがおかしいでしょ
0881デフォルトの名無しさん2010/10/24(日) 13:14:30
何の危険か知らんが、言語で判断するとか無いわ
そういう妄信的なブランド志向は、品質を見定めるのに邪魔になるぞ
0882デフォルトの名無しさん2010/10/24(日) 13:15:19
はげどう
0883デフォルトの名無しさん2010/10/24(日) 13:17:54
例外が出るほうがおかしいってI/Oで読み取りエラーとかブロッキングソケットが切断されたとか
どうすんだ？Cでお得意の無視？
0884デフォルトの名無しさん2010/10/24(日) 13:18:27
例外でも何でも無いなあほうが
0885デフォルトの名無しさん2010/10/24(日) 13:19:33
例外hookしないといけないの？
0886デフォルトの名無しさん2010/10/24(日) 13:21:30
なんだ例外hook一度も書いたことない奴の煽りか、つまんね
0887デフォルトの名無しさん2010/10/24(日) 13:22:48
自分のミスを例外のせいにしたいだけでしょ
0888デフォルトの名無しさん2010/10/24(日) 13:23:33
>>878
このスレって応用利かない奴がいるんだよな
単に例外ってだけ書いて具体例を挙げないほうが良いみたいよ
0889デフォルトの名無しさん2010/10/24(日) 13:31:13
これまでの流れ

Cが一番、JAVAは危険
↓
そんな奴に限って例外処理しない
↓
例外出るほうがおかしい
↓
じゃあ例外出たときは？
↓
自分のミスが原因
0890デフォルトの名無しさん2010/10/24(日) 13:49:19
>>880
そんな想定外な事をしでかしてくれるのが、ユーザとか悪意ある者なんじゃね？
0891デフォルトの名無しさん2010/10/24(日) 13:51:44
無限と有限の使い分けが中で出来てないからでしょ
0892デフォルトの名無しさん2010/10/24(日) 14:09:46
単にケースバイケースって事じゃないか、馬鹿らしい
0893デフォルトの名無しさん2010/10/24(日) 14:11:47
一般人の感覚で実装してますから、何があっても不思議じゃありませんから
0894デフォルトの名無しさん2010/10/24(日) 20:37:39
>>883
> I/Oで読み取りエラーとか
仕様レベルでどうするか決めようね

> ブロッキングソケットが切断されたとか
c じゃなくても eof 扱いで, 想定外の通信終了処理をするのでは?
0895デフォルトの名無しさん2010/10/24(日) 23:33:07
仕様ｗ
0896デフォルトの名無しさん2010/10/25(月) 21:58:38
ここは住人のレベルのバラエティが広いんだな。
>>876-882 みたいな鋭い示唆に富んだ書き込みもあるが…
もうちょっと親切に書いてやろうよ。


>> どうすんだ？Cでお得意の無視？

sorryだなトホホ
オマエさんは（昔の俺みたいに）自分のバグを他人のせいにするタイプじゃ
ないか？気をつけなよ。（俺は>>887じゃないけどさ）

つづく
0897デフォルトの名無しさん2010/10/25(月) 21:59:50
つづき

プログラム言語を本当に使えるアタマのいいひとは、オブジェクト指向や
例外機構も、整数エラーコードでのエラー処理も、単なる道具の一つとして
適材適所で使いこなすもんだぜ。例外だけがエラー処理じゃないよ。
（>>886 例えば、crt0（=mainの外）での例外処理仕様をわかったうえで
あえて書かなくて済むようにプロセス分割設計するひともいるんだぜ）



一般的には、IPネットワークの通信エラーって言うのは、割と頻繁に
（＋自分以外の機械のせいでも）起こりうるものなんだ。
最近の言語（C#とか）のAPIには通信エラーを例外で返すようなものがあって
その場合はしょうがないけど、頻繁に起こりうるエラーは整数戻り値
（エラーコード）で処理したほうが、速くてスマートなプログラムが書けるんだよ。

例外っていうのは元々は、自分の担当してる責任範囲では手に負えないエラーを
大外で捕らえるためのものなんだよ。
メイヤーの「契約に基づくプログラミング」手法のアナロジーで言うと、
「いろいろ手を尽くしたけど、どうしても契約を履行できないことを
（偉い人が頭を下げて）お客（呼び元）に謝るような場合」ってこと。

I/O で読み取りエラーとかブロッキングソケットが切断されたときってのは、
Cだと普通に戻り値でエラーが返ってきて、
それを自分のプログラムで（利用元がカスタマイズ可能な）回数リトライして、
それでもダメだったら例外で返すってのが、スマートだぜ。


例外がないって書き込みは、そういうこと（と俺は理解してるよ）。
エラー処理しないってことじゃない。
0898デフォルトの名無しさん2010/10/25(月) 22:16:03
>> （利用元がカスタマイズ可能な）回数リトライ

って書いたけど、そのカスタマイズ方法っていうのは、
「関数呼び出しごとに呼び元がパラメータで指定」なんかじゃなくて、
「プログラム起動前にレジストリや環境変数に設定しておく。設定が
なければ事前に決めたデフォルト回数」
っていうレベルでいいんだぜ。


>>896が言ってる「仕様レベルで決めような」ってのはね...

リトライ回数なんかは、通信プロトコルを設計するような
設計工程（＝プログラミングより前）で、普通は決めるんだ。

やらしい話だが、
「リトライ回数は、顧客との仕様調整で決定。変えるなら、
プログラム変更して再コンパイル」にしておいて、
「簡単な仕様変更」として顧客から金を取れる、
新人教育のメシの種にするっていうこともあるんだよ。


俺なら、面倒だからカスタマイズ可能な項目としておいて、
客に勝手にしろ、といいたいけどな。
0899デフォルトの名無しさん2010/10/25(月) 22:16:45
すまん >>894 だ
0900デフォルトの名無しさん2010/10/26(火) 11:27:54
おーい、>901
>896-898な、ちょいくどいし長すぎるんだわ
スマートになるように3行ぐらいに要約しておいてくれ
0901デフォルトの名無しさん2010/10/26(火) 15:37:15
すまんかった

>>883 >>886 >>889 はレベルが低い
もっと勉強しろ

これでいいか
0902デフォルトの名無しさん2010/10/26(火) 16:55:12
最終的に>>892
0903デフォルトの名無しさん2010/10/26(火) 22:25:48
ぱっと見は例外なんだけど、実際にはただの条件分岐　みたいな書き方って
うまい方法ないかな

プログラムの7割がエラー処理になっちゃうからあんまり美しくないというか
0904デフォルトの名無しさん2010/10/27(水) 00:00:31
ぱっと身は条件分岐なんだけど, 実は例外ってのなら結構見掛けるが
逆は, あまりみたことない

うまいやつだと, 「実は例外」の部分さえ条件分岐しないことあるからなぁ

Java 辺りだと普通は条件分岐するようなところまで例外になるしな
0905デフォルトの名無しさん2010/10/27(水) 02:25:53
通信プロトコル制御の場合は7割がエラー処理だから、
必然的にエラー処理を想定したロジックになるんだよね。
言い換えると(プログラミング言語の例外機構ではなく)
エラーを条件分岐で扱うロジックによって組立てることになる。
エラー処理を正常処理に持ち込む、あるいは正常とは
エラーの一種であるという発想による設計が求められる。

アプリケーションプログラムであれば、エラーが発生しても
メッセージを表示して続行するか、あるいはダイアログでユーザに
判断を委ねることが可能だから、例外機構に頼ることは間違いじゃない。
ただし、通信プロトコル制御はシステムソフトウェアの一種だから、
例外発生は、即システム停止(UNIXであればpanic、Winであればblue screen)、
あるいはアプリケーション全体の強制異常終了の場合にしか使い道が無い、
といっても間違いではないと思う。
0906デフォルトの名無しさん2010/10/27(水) 07:44:11
そこで検査例外に意味がでてくるのですよ。

いや言ってみただけ。
0907デフォルトの名無しさん2010/10/27(水) 09:58:44
panicとかブルースクリーンまで行かなくても、例外の使い道あるよ。
プロトコルデーモンだったら単にプロセス終了するため、でいいと思う。


C++で標準になった「テンプレートライブラリ」にはリンクリストやらが
用意されてて、要素追加のときにメモリブロックの追加確保が発生して
万一メモリ確保失敗するとbad alloc 例外を投げる仕様になってる。

C++ではユーザプログラムが拾ってない例外は、crt0がアボート処理
（メモリ全解放してプロセス終了）してくれる仕様になってる。

ということは、bad alloc例外は、いちいちプログラムで拾わずにcrt0に
まかせてプロセス終了し、あとはプロセスの生存監視をしてクラスタ切り替えする
仕組みに任せる、でOKってこと。
リンクリストの追加削除でいちいちメモリエラー拾うコードがなくなってすっきり。

最大数設定とか最大通信負荷のテストを結合テスト以降で必ずやるから、
本番環境でメモリ不足が発生することは基本的にありえないしね。


通信エラーなんか例外で扱うことじゃない、正常系の一部だってことで同意見。
JavaやC#のライブラリつくったやつは、例外の意義がわかってないアホ。
0908デフォルトの名無しさん2010/10/27(水) 18:28:53
>>905
だからそれがなんとかならないかな という話なんだが。
仕方ないで済ますのは進化が無い
レス数が900を超えています。1000を超えると表示できなくなるよ。