問題タブ [reliability]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
mysql - MySQLテーブルの読み取り順序の信頼性
アプリケーションからMySQLテーブルを1行ずつ読み取るときに、テーブルは常に上から下に、完全な順序で次々に読み取られると想定しても安全ですか。
EGテーブルが一意のIDで並べ替えられていて、C++を介して一度に1行ずつ読み込んだ場合。毎回正確に一意のIDの順序で各行を取得すると想定しても安全ですか。
私の直感は、それは安全な仮定ではないということですが、そのための技術的な理由はありません。
私のテストでは、テーブルの行が順番に提供されることが常に示されていますが、それに依存するのは緊張します。結果として、私はプログラムをこの仮定に依存しないように作成します。これにより、プログラムは少し複雑になり、効率が少し低下します。
ありがとうC
synchronization - 両将軍の合意
信頼できないチャネルで合意プロトコルを見つけようとしています。基本的に二者(AとB)が何かをするのに同意しなければならないので、それは2人の将軍の問題です.
防弾ソリューションがないため、これを実行しようとしています。
- A は連続してシーケンス 1 のメッセージを送信します
- B がシーケンス 1 を受信すると、連続してシーケンス 2 で応答します。
- この時点で、A は seq 2 を受信するため、seq 3 の送信を開始します。
- ...
私の質問。両当事者は、いつ行動を起こすことができると結論付けることができますか? 明らかに、条件を設定することはできません。「10 件のメッセージを受信した後に実行する」というのは、最後の送信者はメッセージ 10 件が到着したという確実性を持たないためです。振り出しに戻ります。
別のアイデアはどうですか:
- このように、事前に定義された時間、通信を続けます。その期間の終わりに、両当事者はチャネルの信頼性について考えます。それは受け入れられるでしょうか?
erlang - Erlangの99.9999999%(ナインナイン)の信頼性
Erlangは、実稼働システムで20年以上使用されており、稼働率は99.9999999%であると報告されています。
私は次のように計算しました:
つまり、システムのダウンタイムは20年間で1秒未満です。私はこれの妥当性に異議を唱えようとはしていません。システムを(故意にまたは偶然に)わずか0.631秒でシャットダウンする方法に興味があります。大規模なソフトウェアシステムに精通している人は、これを私たちに説明できますか?ありがとうございました。
処理装置(またはマシン)のクラスター全体でサービスのダウンタイムを計算する方法を知っている人はいますか?
c++ - グーグルプロトコルバッファ-ビットエラーの確率とそれらを減らす方法
かなり大量のグーグルプロトコルバッファメッセージをVPN経由でVPN経由でインターネット経由でTCP経由で送信しますが、エラー率が比較的高いように感じます(たとえば、ブールフィールドがfalseからtrueまたはsthに類似しています)。10,000人に1人から50,000人に1人の間の何か。
それは可能ですか?ウィキペディアは、TCPのチェックサムは弱いと述べていますが、これは通常、基盤となるプロトコルで修正されています。
TCPチェックサムは、最新の標準による弱いチェックです。ビットエラーレートが高いデータリンク層には、追加のリンクエラー訂正/検出機能が必要になる場合があります。弱いチェックサムは、CRCの一般的な使用、またはPPPやイーサネットフレームで使用されるようなTCPとIPの両方の下のレイヤー2でのより優れた整合性チェックによって部分的に補償されます。
予想されるエラー率がどうあるべきかを経験した人はいますか?上記のレートが可能である場合、それを修正するための推奨/最も簡単な方法は何でしょうか?フィールドを複製しますか?メッセージを2回送信しますか?それとも、信頼性を高めるためにできることが他にありますか?
ありがとう
c - ユーザーがすべての列名を非表示にするときに、C API を使用して SQLite 行 ID を確実に取得/利用する方法は?
SQLite のドキュメントによると、すべてのテーブルにはデフォルトで行 ID があり、削除することはできません。rowid
そして、このROWIDには、oid
またはでアクセスできます_rowid_
。
いずれにせよ、データベース ユーザーは自由に名前を付けて新しい列を追加でき、列は非表示になります。行 ID にアクセスする唯一の方法は、新しい列を作成することINTEGER PRIMARY KEY
です。
これが私の現在の理解です。これにより、ユーザーがすべての列を非表示にし、ユーザーが PK 列を作成しなかった場合、 ROWIDを取得する信頼できる方法がありません。一時的な PK 列を追加することも考えましたが、これも信頼できません。これが本当なら、意味がありません。データは常に利用可能であり、適切なインターフェイスがないためにアクセスできないからです。
したがって、このデータに確実にアクセスする方法が必要だと思います。しかし、C API では何も見つかりませんでした。これについていくつかのガイダンスがありますか?
c# - 破損状態の例外処理の信頼性
現在、 C# / .NETの信頼性機能と例外処理について調べています。
これらは、特にHandleProcessCorruptedStateExceptions
属性とCERですPrepareConstrainedRegions
。
SecureString
これは、例外的な状況でもデータを暗号化することが非常に重要な場所であるため、クラスの参照ソース コードを読んでいたところ、次のような場所が見つかりました。
catch
ブロックの理由は何ですか?finally
ブロックはデータを再保護するのに十分ではありませんか?
それとも、これらの破損状態の例外はcatch
、後でアプリケーションに影響を与えて終了するだけでしょうか?
actionscript-3 - 信頼性の低いインターネット上でのデータ永続化のためのアプリケーション設計
Wi-Fi経由でインターネットを介してWebサービスと通信するFlexアクションスクリプト3スケジュールリマインダーアプリがあります。問題は、Wi-Fi 接続が不安定で、ドロップアウトが頻繁に発生することです。アプリが通知するスケジュールはあまり頻繁に変更されません。そのため、毎日/毎時間スケジュールを見つけるために Web サービスを呼び出す代わりに、アプリはデータをローカルに保存できます。また、ユーザーがアプリでスケジュールを更新すると、Web サービスが更新され、スケジュールのタスクが完了します。このデータはローカルに保存することもできるため、ユーザーが次にアプリを使用するときにインターネット接続があれば、アプリは Web サービスを更新できます。このような場合のアプリケーション設計の提案は何ですか? 例はありますか?
java - JVM コンソール アプリケーションで ^C を処理する方法は?
JVM で実行した場合 (実際には Scala で記述されていますが、解決策は Groovy、Clojure、または純粋な Java でもほぼ同じであると考えがちです)、私のコンソール プログラムは、ユーザーがCtrl+を押しCて (またはシステムのシャットダウン シーケンス、プログラムに違いがあるかどうかはわかりません)、アプリケーションが変更する外部リソース (データベース、ファイル、Web サービスの抽象化されたリソース) が予測可能な非論理的に壊れた状態?
c# - C# 必要な UDP データがクライアント/サーバーに確実に届くようにするにはどうすればよいですか?
私は最近、必要に応じてワールド データ、エンティティ データ、チャット データなどを更新して送信する PC 用の C# および XNA で作成している 2D シューティング ゲーム用の UDP サーバーを作成しています。
最近、プレイヤーが武器を変更する方法を作成していたときに、ある質問が頭に浮かびました。武器の変更を要求するサーバーに送信されるパケットが失われた場合はどうなりますか? この質問は、私に別の質問を考えさせました。クライアントとサーバーが特定のパケットまたはデータ ブロックの受信を確認できるようにするにはどうすればよいですか?
そのため、この問題に取り組むために、次のような単純な解決策を考え出しました。
- サーバーは確認応答を必要とするパケットを送信します。
- クライアントはパケットを受信し、確認パケットを送信します。
- サーバーは、クライアントがデータを確認したかどうかを確認します。クライアントが送信していない場合は、データを再送信します。
提案されたソリューションはかなり良さそうに見えますが、確認応答パケットが失われたり、意図しないことが起こったりした場合はどうなるでしょうか?
この問題のより良い解決策は、TCP と UDP を使用するサーバーとクライアントを作成することです。TCP はそこに到達し、順番に/1 つの平和で到達する必要があるデータに使用され、UDP はそこにすばやく到達する必要があり、損失やエラーに対処できるデータに使用されますか?
TCP/UDP サーバーとクライアントがより適切な選択である場合、どのようなリスクがあり、それを実装するにはどうすればよいですか?
ありがとう。