問題タブ [reliability]

ドメインソケットで使用するプロトコルを見つけようとしていますが、ドメインソケットがどれほど盲目的に信頼できるかについての情報が見つかりません。

データが失われる可能性はありますか? メッセージは常に送信と同じ順序で受信されますか? データグラムソケットを使用している場合でも?

転送はアトミックですか? ソケットを読み取るとき、1 回の読み取りでメッセージ全体を取得できると信頼できますか?それとも自分で確認する必要がありますか?

私はトランザクショナル メモリと、システム プログラミング (データベース、オペレーティング システム、サーバーなど) の実行可能性についていくつかの作業を行ってきました。トランザクションを使用した私自身の経験と、実際のコードでトランザクションを使用するコミュニティがいかに少ないかを見てきたことから、次のような疑問が生じました。実動コードを作成している開発者が、業務にトランザクション メモリを使用することを納得させるにはどうすればよいでしょうか?

一般採用になるのでしょうか？高速？信頼性の向上？いくらで？

まだ見ていない方のために説明すると、メモリ トランザクションはデータベース トランザクションのように動作します。操作は (明らかに) 並行して進行し、2 つのトランザクション間で競合が発生した場合 (両方とも同じ値を書き込むなど)、トランザクションの一方または両方が実行されます。ロールバックされて再起動されます。

トランザクション メモリにはいくつかの利点があります。

1. 信頼性デッドロックから完全に解放されます (たとえば、間違った順序のロック)。
2. パフォーマンスロックの競合が少ない場合は速度が向上します。
3. プログラマビリティ 多くの同期オブジェクトを管理せずに、きめ細かい同時実行制御を実現します。

ただし、 TM が正しく、完全で、高速に実装されていると仮定しても、ロックと比較すると、このプリミティブには既知の欠点があります。

1. トランザクションは数回実行される可能性があるため、経験的な実験以外でパフォーマンスを予測することはより困難です。

   パフォーマンスのバグを再現できますか?

2. 正しい実装間で異なるポリシー決定がいくつかあります。たとえば、別のトランザクション内で終了するトランザクションはどうなりますか? 今コミットしますか、それとも待ちますか?

   コードの局所的な効果を十分に理解できるでしょうか?

3. ロールバックされるトランザクションで取消不能な動作 (「ミサイル発射」コマンドの送信など) をサポートするために、ランタイムはより複雑になります。

   コードのグローバルな影響を適切に理解できますか?

最後に、ソフトウェア実装が最初に使用される可能性が高いため (いくつか例を挙げると、C、C++、Haskell、Clojure、および Scala には既に実装があります)、実際にはパフォーマンスの問題があります。競合が中程度の場合、ソフトウェア トランザクションはパフォーマンス ヒットを伴います。

パフォーマンスの予算はいくらですか? メリットが潜在的なコストを上回るのはどの時点ですか?

信頼できる UDP 層をテストするための失敗シナリオの良いリストは何ですか? 以下のケースを考えました。

• ドロップ データ パケット
• ACK、NAK パケットのドロップ
• 順不同でパケットを送信します。
• 最初のハンドシェイク パケットをドロップする
• クローズ / シャットダウン パケットのドロップ
• 重複パケット

信頼できるUDPが処理する必要がある他のケースを特定するのを手伝ってください?

分散システム用の商用ロギング フレームワークを探しています。このフレームワークでは、リモート サーバー上の .NET アプリケーションがメッセージをログに記録し、中央の場所で収集できるようにする必要があります。可能であれば、中央の場所は SQL Server データベースにメッセージを保存する必要があります。

要件：

1. ネットワークの中断により中央ロケーションへのメッセージの即時ディスパッチが妨げられている場合でも、リモート サーバーでメッセージのロギングを開始できます。
2. 中央の場所へのメッセージのディスパッチは、.NET アプリケーションを実行しているプロセス以外のプロセスで処理して、ASP.NET アプリケーションまたは Web サービスのパフォーマンスが低下しないようにする必要があります。
3. 中央の場所へのメッセージの最終的な配信を保証します。たとえば、ネットワークが応答しない期間の終わりに向けてリモート サーバーが再起動した場合、ログに記録されたメッセージは、リモート サーバーと通常のネットワーク状態が復元されたときに配信されます。

私は、非 SQL エンジンを使用するか、小規模ビジネス向けのドキュメント管理システム用の通常の SQL エンジンを使用するかを決定しています。

私はfirebird/sqlサーバーの経験があり、信頼性の良いトラックを見つけました（特にfirebirdで）。

この市場は、くだらない「サーバー」（クローン製の PC、マヨリティ）、安価なハードディスク、RAID などをめったに使用しないものでいっぱいで、電源オフが正常な場所にあるものもあれば、UPS を持っていないものもあります。 ... (外部サーバーへのオフサイト自動バックアップを含めますが、内部設定は変更しません)。(私はそのような適切なセットアップに関するエンドユーザー教育について知っていますが、それに依存するのはばかげているので、ポイントに固執してください)

設計の観点からは、スキーマのないデータベースが私のシステムに適した方法ですが、実際のソリューション (MongoDb、Tokyo Cabinet など) のいずれかが火の鳥やサービスのクラッシュ、誤動作、乱用のようなものではないか心配です。データの破損は非常にまれです。

計画は、そこにオフィスのドキュメントを保存し、中央リポジトリを提供することです。

デイリービルド内でVisualC++コンソールテストプログラムを実行します。時々、テストは他の開発者によって不適切に変更された関数を呼び出し、無限ループに陥ってハングし、ビルドをブロックします。

できるだけシンプルなウォッチドッグソリューションが必要です。これが私が思いついたものです。テストプログラムのエントリポイントで、継続的にループし、経過時間をチェックする別のスレッドを開始します。事前定義された期間を超えると、TerminateProcess（）が呼び出されます。擬似コード：

このソリューションは、別のマスタープログラムとして実装されたウォッチドッグよりも悪いですか？

現在のアプリケーションでは、Simple Java Mailを使用して 1 日に 2 通の電子メールを送信していますが、クライアントに届かない電子メールもあります。

アプリケーション サーバーのログに基づいて、メール サーバーのタイムアウトが 2 回発生しましたが、メールが見つからないすべてのケースを説明しているわけではありません。再試行機能を追加するとタイムアウトの問題を解決できますが、一般的にメールの信頼性を向上させる他の方法はありますか?

当社の製品は分散システムです。私が取り組んでいるモジュールはかなり新しく、非常に厳密で、よくテストされています。これらは、最近のベスト プラクティスを念頭に置いて開発されました。その他のモジュールは、レガシー ソフトウェアと見なすことができます。

私は自分が担当しているモジュール内で発生するすべてのことに注意を払っていますが、他のモジュールから送信された不良データを処理するというプレッシャーに常にさらされています。本質的に、私は「フェイル ファスト」原則の開発者であり、その結果、問題が発生した場合、通常はモジュールのエラーの可能性を排除することができます。責めるということではなく、間違った場所でバグを追跡する無駄な労力を節約するだけです。

しかし、私が常に反対している議論は、「このようなものを本番環境で失敗させることはできません。顧客はこれが機能することを期待しています。この問題を回避してみませんか」というものです。そして、これは頑強さの議論になります。受け入れるものにはリベラルであり、送信するものには保守的であることです。

また、これらはほとんど断続的な問題であることにも注意してください。それらは統合テストで見られますが、再現するのは困難です。タイミングと並行性が関係しています。

2 つの原則のバランスをとるのに苦労しています。その理由の 1 つは、例外的なデータを許可して伝播し始めると、問題が発生し、自分のシステムにあまり自信が持てなくなるのではないかという心配です。しかし、他のモジュールが間違ったデータを送信している場合でも、システムを動作させ続けることに反対することはできません。他のモジュールが修正されていない理由は、それらが複雑すぎて壊れやすいためですが、私のモジュールはまだ明確で安全に見えます. しかし、私がプレッシャーに抵抗しなければ、私のモジュールは、私が今まで拒否してきたのと同じ問題をゆっくりと抱え込むことになります.

システムが本番環境で「クラッシュ」することはありませんが、モジュールが単にエラーをオペレータに表示し、サポートに連絡するように依頼する場合があります。クラッシュは大きな問題ですが、エラーを明確に報告しているのであれば、これは正しいことではないでしょうか? 私の同僚は、顧客に問題を見せたくないだけだと思います。しかし、私のモジュールは、顧客の入力ではなく、製品内の他のモジュールからのデータを拒否しています。ですから、私たちは問題に取り組んでいないだけのように思えます。

では、私はもっと現実的になる必要がありますか、それとも自分の立場を維持する必要がありますか?

アプリケーションの実行中に、使用する共有ライブラリの1つが書き込まれるか切り捨てられると、アプリケーションがクラッシュします。OS（この場合はSolarisですが、Linuxやその他の* nixにも当てはまると思います）は、関連するiノードを削除しないほど賢いため、ファイルを移動したり、「rm」を使用してファイルを一括削除したりしても、クラッシュは発生しません。いずれかのプロセスでファイルが開いている間。

共有ライブラリのインストールを実行するシェルスクリプトがあります。場合によっては、最初にアンインストールせずに、すでにインストールされているバージョンの共有ライブラリを再インストールするために使用されることがあります。アプリケーションはすでにインストールされている共有ライブラリを使用している可能性があるため、スクリプトがファイルをrmしたり、邪魔にならない場所に移動したりするのに十分スマートであることが重要です（たとえば、アプリケーションがないときにcronが空にする可能性のある「削除済み」フォルダーに移動する）上書きまたは切り捨てられないように、新しいものをインストールする前に実行されます）。

残念ながら、最近、インストール直後にアプリケーションがクラッシュしました。一致？見分けるのは難しいです。ここでの本当の解決策は、古い巨大なシェルスクリプトよりも堅牢なインストール方法に切り替えることですが、切り替えが行われるまで、いくつかの追加の保護があると便利です。シェルスクリプトをラップして、ファイルの上書きや切り捨て（理想的には大音量での失敗）から保護し、それでもファイルを移動またはrm'dできるようにする方法はありますか？

移動/削除と上書き/切り捨てを区別できないため、標準のUNIXファイルパーミッションではうまくいきません。エイリアスは機能する可能性がありますが、どのコマンド全体をエイリアスする必要があるのか​​わかりません。truss / straceのようなものを想像しますが、各アクションの前に、実際に実行するかどうかをフィルターに対してチェックします。意図的に悪意のあるスクリプトに対しても機能する完璧なソリューションは必要ありません。

.NETでWPFを使用する場合と、WCFサービスに接続するアプリのGUIフロントエンドにSilverlight4を使用する場合の違いを調べています。

Silverlight 4のnet.tcpバインディングは、トランスポートレベルの信頼性のみをサポートしていることを読みました。WPFデスクトップアプリを使用すると、メッセージレベルの信頼性を使用できます。

実際の違いは何ですか？トランスポートレベルの信頼性により、すべてのTCPパケットが確実に通過する場合、それはすべてのWCF SOAPメッセージも通過することを意味しませんか？