サードパーティのソフトウェアアプリへのtcpipソケットインターフェイスがあります。私はこのインターフェースをいくつかの顧客サイトに問題なく実装しました。しかし、最新の顧客は...問題があります。どちらかの側でアプリへのログインをオンにし、PCにWiresharkをインストールして生のtcpipトラフィックをログに記録しました。これで、サーバーアプリがメッセージを正常に送信し、PCがメッセージを受信したが、クライアントアプリはメッセージを認識しないことを証明しました。（これは完全に断続的な問題であるため、トラブルシューティングが非常に面倒です。）
ソケットの詳細は非常にシンプルです。1つのソケットがサーバーとPC間の双方向通信を処理します。メッセージはプレーンなASCIIテキストであり、かなり短いです（XMLではありません）。サーバーは最初のメッセージを送信して通信を開始し、次にクライアントはいくつかのメッセージで応答します。アプリの実行中は、ソケットは常に開いたままになります。クライアントアプリは、エンドユーザーが一度に1つのケースしか処理できないように設計されているため、メッセージの衝突が発生することはありません。ある種のポーリングが設定されており、サーバーからの開始メッセージが表示されるまでアプリは「休止状態」になります。
サードパーティベンダーから、開始メッセージを送信する前に数秒の遅延を追加するようにアドバイスされました。それがどのように役立つのかわかりません。クライアントが「スリープ」していて、メッセージを待機しているソケットをポーリングしている場合、最初のメッセージの前に遅延を追加するとどのように役立ちますか？2つのメッセージを送信して、2番目のメッセージが失われるわけではありません。最初のメッセージが失われています。そのため、そのメッセージを今すぐ送信するか、2秒後に送信するかが重要かどうかはわかりません。
私は彼らに尋ねましたが、彼らは私に詳細を教えてくれませんでした。彼らが私に開示したくないのは、彼らのコーディングにおけるいくつかの専有的な詳細である可能性があり、それは公正です。ソケットプログラミングについて常に新しいことを学んでいるので、ここで質問しています。たぶん皆さんは、tcpipソケットのポーリングがメッセージのタイミングによってどのように影響を受ける可能性があるかについていくつかの光を当てることができますか？