ソケット接続タイムアウトはネットワークによって異なります

Question

私はかなり興味深い問題があります。お互いに物理的に重複している2つのネットワークがあります（ネットワークAとネットワークB）。それらは異なるサブネット上で実行されます。

私はネットワーク上でお互いにクラスタリングするデバイスのフォールトトレランスの改善に取り組んでいます。私が試しているテストケースの1つは、誤った設定が導入されたときのこれらのデバイスの動作です。

デバイスX IP：10.200.234.127 サブネットマスク：255.255.254.0デフォルトゲートウェイ ：10.200.234.1

デバイスY例えば、私は次のインターフェイス設定の2つのデバイスを持って言うことができます IP：10.200.234.127 サブネットマスク：255.255.254.0 デフォルトゲートウェイ：10.200.234.1

これら2つのデバイスは、クラスタHの放送を介して互いを発見イートビート。ハートビートには、デバイスのIPアドレスなどが含まれているため、互いに通信できるようになります。かなり標準的なもの。

デバイスX IP：192.168.1.115 サブネットマスク：255.255.255.0 デフォルトゲートウェイ：192.168.1.1今、私はこれらのデバイスの1つが異なるsunbetのために設定されるように、ネットワークの設定ミスを導入言うことができます

ここでは、両方のデバイスがクラスタブロードキャストから互いに学習している（同じスイッチ上に物理的に接続されている）場合があります。ただし、期待どおり、期待どおりには互いに通信することはできません。しかし、これらのデバイスが相互に通信しようとすると、タイムアウトの接続に関するいくつかの奇妙な動作が発生しています。たとえば、デバイスがネットワークAに接続されている場合、接続は数秒でタイムアウトになります。今、私は両方のデバイスをネットワークBに配置すると、私は全く異なる動作を見ます。ネットワークB上では、デバイス間のソケット接続を確立するconnect（）呼び出しがすぐに失敗することはありません。むしろ、彼らは最終的にあきらめるために189秒かかる（wiresharkで確認されたように3,6,12,24,48、および96秒で再送信する）このバックオフと再送信サイクルに入ります。

なぜ私はconnect（）コールがネットワークAではなくネットワークBですばやく失敗するのでしょうか。私はブロッキングソケットとconnect（）とnon-blockingソケットconnect（）の呼び出しに続いてselect（）の呼び出しが続きます。どちらの場合も、189秒以上早くに接続を断念することはできません。私は、コールを選択してより早く放棄するために、より短いタイムアウトを課すことができることを知っていますが、それはここでのポイントではありません。私はこの問題を引き起こしているこれらの2つのネットワークで何が異なるかを理解しようとしています。

Answer 1

多分、より多くのアドレスを与える必要がありますか？ IPが何であるかは明確ではありません。あなたは、ルーティングの失敗を取得している高速の場合は遅い場合（ターゲットが間違ったネットマスクを持っているので、何の応答）を使用すると、ARPの失敗を取得していないしている

で

• ：

  私の推測では、ということです。ホストのネットマスクが正しくない場合は、ARPを試行しません。

エラーコードは異なる必要があります。