問題タブ [reliability]

以下に示す並列システムの各サブシステムの可用性が 70% である場合、システム全体の可用性を 99% 以上に高めるために並列に構成する必要があるサブシステムの最小数はいくつですか?

1 つのサブシステムが実行されている限り、システム全体が実行されていると想定します。

図:

http://postimage.org/image/tdv2xfwk/

答えは 4 ですが、なぜだかわかりません。

私は信頼できるセッションの非常に興味深い振る舞いに遭遇しました。netTcpバインディング+デュプレックスチャネル+信頼できるセッションを使用しています。

channel.faultedでリッスンしようとしているときに、セキュリティモードがトランスポートに設定されている場合、クライアントが切断されるとすぐにfaultedイベントが発生します。

ただし、バインディングのセキュリティモードを[なし]または[メッセージ]に設定すると、同じ状況で障害イベントが発生しなくなりました。最終的には、サーバー側でReciveTimeoutの半分に障害が発生します。これは、信頼できるセッションがその時点でハートビートメッセージを送信することを理解しています。

問題は、なぜwcfバインディングが時間どおりに失敗しないのかということです。

この場合の回避策は、接続を手動で「ping」できることです。

rvm をインストールした ruby​​ 1.9.2 p136 と rails 3.0.3 を使用しました。開発は簡単ですが、展開の経験はほとんどありません。

Passenger3 + apache2? lighttpd プロキシ + 雑種?

本番サーバーで使用したWebサーバー、監視、およびツールを簡単に説明できる人はいますか?

私は主に職場で Delphi を使用しており、日付時刻の比較を含む徹底的な単体テスト中に、計算された日付などを比較する場合、equals 演算子を使用した直接比較は十分に信頼できないことがわかりました。 Delphi での日付比較用の組み込み関数。

C# では習慣により、標準の演算子を使用して日付/時刻を比較します=<>。DateTime.CompareやDateTime.Equalsなどの日付時刻比較用の同様の関数があるため、精度と信頼性の観点から、代わりに組み込み関数を使用する必要がありますか?

演算子を使用するよりも正確な比較ができますか?

winsock の send() または WSASend() を使用して送信されたデータが本当に宛先に配信されているかどうかを確認する方法はありますか?

サードパーティのサーバーと通信するアプリケーションを作成していますが、しばらく作業した後にダウンすることがあり、そのサーバーに送信されたメッセージが配信されるかどうかを確認する必要があります。問題は、サーバーが既にダウンしている場合でも send() の呼び出しがエラーなしで終了し、次の send() のみがエラーで終了することがあるため、前のメッセージが配信されたかどうかわかりません。

TCPレイヤーには、送信された特定の（またはすべての）パケットが確認応答されたかどうかの情報があると思いますが、ソケットインターフェイスを使用して利用できない（または方法が見つかりません）。

最悪なことに、サーバーのコードを変更できないため、配信確認メッセージを受け取ることができません。

クォーター/ハーフ/ピリオドの経過時間を追跡する必要があるスポーツ アプリを作成しています。経過時間は秒単位まで正確である必要があります。ユーザーが電源ボタンを押して明示的にデバイスをスリープ モードにした場合でも、ゲーム クロックは動作し続ける必要があります。

これを最初に試みたのは、Handler.postDelayed()を使用して 200 ミリ秒ごとにクロック ティックをトリガーし、WindowManager.LayoutParms.FLAG_KEEP_SCREEN_ONを使用して、画面のタイムアウトによって「クロック」が停止しないようにすることでした。しかし、電源ボタンを押してデバイスを手動でスリープ状態にすることで、このアプローチを回避できることをすぐに知りました。さらに、postDelayed() アプローチでは、明らかに run() メソッドで費やされた時間の結果として、クロック ドリフトが発生しています。実際の数値は依然として正確ですが、たとえば、ユーザーが簡単に理解できる 5 秒の境界に合わせる代わりに、関係するタイマーがドリフトし始め、理解できるユーザーの混乱を招きます。

少し調査した後、サービス、Java タイマー、AlarmManager、およびPartialWakeLockを使用してタイマーを実装するためのテクニックを見つけました。サービス自体は、デバイスがスリープ状態になることに関連する問題を解決しません。Java タイマーは、サービスと同様に、デバイスがスリープ状態になる問題を解決しません。AlarmManager は良いアプローチのように思えますが、これは AlarmManager の適切な使用方法 (つまり、アラーム間の非常に短い間隔) ではないことを懸念しています。PartialWakeLock を使用することも有望に見えますが、それだけでは私が経験しているクロック ドリフトの問題には対処できません。

AlarmManager と PartialWakeLock の組み合わせを試してみます。アイデアは、AlarmManager がクロック ドリフトと戦うのに役立ち、PartialWakeLock がコードをシンプルに保つのに役立つ (指を交差させた) というものです。このアプローチにより、省電力、コードの複雑さ、およびユーザーの期待の間で合理的なバランスが得られることを願っています。どんなアドバイスでも大歓迎です。

ありがとう、

リッチ

Linuxで動作するネットワークアプリケーションがあります。私がやりたいのは、アプリケーションがLANに存在することをアナウンスできるようにしてから、他のアプリケーションにいくつかの変更について通知できるようにすることです。LAN内の他のホストでアプリケーションのインスタンスがいくつ動作しているかわからないため、SCTPを使用できません。マルチキャスト通信が唯一の方法です（または他の解決策を知っていますか？）。

マルチキャストアドレスで送信したい構造は固定サイズ（320バイト）で、実際には数値とビットフラグの構造であるバイナリデータが含まれています。

UDP通信の信頼性を少し高めることができるよく知られたプログラミング手法があるかどうか疑問に思います。私は2つのことだけを理解しました：

1. 私は、320バイトよりも小さいrecvmsg（）によって受信されたすべてのパケットをドロップします。
2. すべてのパケットをよく知っているヘッダーとフッターで囲み、新しいメッセージを受信するたびにそれらをチェックしますが、パケットはまだ中央のどこかで破損している可能性がありますか？

編集： PGNプロトコルを見つけましたが、x86で動作することがわかっているのはLinuxの実装だけです。ARMアーキテクチャでもプログラムを実行したいので、これは部分的な解決策です。

私のアプリケーションは、デスクトップ クライアントと Web API アプリケーションです。私は両方のプログラムを書いています。

インターネットは古いリクエストを破棄しますか? それが単に古いリクエストなのか重複したリクエストなのか、違いはありますか?

HTTP リクエストを再試行することが、HTTP でほぼ完全なエンドツーエンドの信頼性を確保する唯一の方法ですか、それとも、SOAP を使用せずに引数またはヘッダーを設定するだけで SOAP レベルの信頼性を達成する方法はありますか? 私のアプリは SOAP を使用しておらず、Python 標準ライブラリの同期要求 (マルチスレッド) のみを使用しています。

Web サービスを広く使用するモバイル アプリケーションを開発しました。共有ホスティング サーバーに接続して、リアルタイムの情報を取得します。したがって、サーバーが稼働していることを確認することは非常に重要です。そうしないと、顧客を失うことになります。

いくつかの背景。アップタイムの点であまり信頼性がなかったため、3 つ以上のホスティング プロバイダーを変更しました。私の現在のホスティングは、以前の 3 つよりもはるかに優れています。1 年以上使用していますが、99.9% の稼働率が保証されていますが、今日は約 3 時間のダウンタイムがありました。それが私がこの投稿を作成している理由です。

私たち小規模な開発者のすべてが、高価な専用ホスティングを提供したり、自宅に独自のサーバーを所有したりできるわけではありません (決してダウンしないという保証はありません)。私の場合、非常に妥当な月額 $10 ～ 15 のホスティングを共有しても問題ありません。それらの数時間を除いて、ダウンしている可能性があります。

これに対処しなければならない 1 つのアイデアは次のとおりです。別のプロバイダーと 2 番目の (異なる) 共有ホスティングを用意し、プライマリ ホストがダウンしたときにこの 2 番目のホスティングをデフォルトで使用するようにアプリを作成します。両方が同時にダウンすることはほとんどありません。専用ホスティングの場合の 10 倍ではなく、月に数ドルの追加料金を支払うだけです。

このような状況に陥ったのは私が初めてではないと確信しています。この問題に対処するための良い方法を見つけた人はいますか? 結局のところ、プライマリ サーバーの短いダウンタイムについて話しているだけです。

ご提案いただきありがとうございます。

私は、自分のゲーム開発サイド プロジェクト用に独自のネットワーク エンジンを作成する作業を行ってきました。これには、信頼できないメッセージ、信頼できるメッセージ、および順序付けされた信頼できるメッセージを持つオプションが必要です。ただし、信頼できるプロトコルと順序付けられた信頼できるプロトコルに必要なすべてのメカニズムを特定できたわけではありません。

UDP を介した信頼性の高いレイヤーに必要なメカニズムは何ですか? 追加の詳細をいただければ幸いです。

これまでのところ、これらが要件であることがわかりました。

• 受信したメッセージをシーケンス番号で確認します。
• 再送信時間が経過した後、未確認のメッセージを再送信します。
• 適切な再送信時間を計算するために、各宛先の往復時間を追跡します。
• 重複パケットを特定して削除します。
• オーバーフローするシーケンス番号を処理します。

これは私のアーキテクチャに影響を与え、シーケンスとタイムスタンプを含む信頼性の高いメッセージ ヘッダー、受信したシーケンスとタイムスタンプをエコーする確認応答メッセージ、アドレスに基づいて適切な再送信時間を追跡するシステム、および a) メッセージを受信して​​ユーザーが受信できるようにキューに入れるスレッドを備えています。 、b) 信頼できるメッセージを確認し、c) 再送信タイマーの期限が切れた未確認メッセージを再送信します。

注: 信頼できる UDP は TCP と同じではありません。注文された信頼できる UDP でさえ、TCP と同じではありません。私は、本当に TCP が必要であることを密かに認識していません。また、誰かがセマンティクス ゲームをプレイする前に、はい...信頼できる UDP は「矛盾した表現」です。これは、信頼性の高い配信を実現する UDP 上のレイヤーです。