私はPython3/asyncio(Protocol)で書かれた私のサーバアプリケーションに問題がありますが、別のバージョンを試したのでpythonやasyncioにあまり関係ないと確信していますいくつかの5ライナーは、ソケットインターフェイスとちょうど。 多くのクライアントハードウェアTCP/IP < - > RS232コンバーターとの同時通信です。これは、書き込みをブロックするスレッドではなく、asyncioが使用される理由です。Python:TCPの壊れたルートが痛いほど検出が遅い
定期的な短いデータ送信があります。
asyncio - Fatal read error on socket transport protocol
<_SelectorSocketTransport fd=11 read=polling write=<idle, bufsize=0>>
Traceback (most recent call last):
File "/usr/lib/python3.5/asyncio/selector_events.py", line 663, in
_read_ready
data = self._sock.recv(self.max_size)
OSError: [Errno 113] No route to host
それが起こる、私は15分のためのシグナリングいますを意味している「すべては大丈夫ですが、それはにISN、しかし15分後:私は物理的に接続を切断して、例外が発生するのを待つときに問題が発生しますそれは耐え難いほど長く、機能が壊れている。 動作は、Ubuntu 16.04、Ubuntu 14.04、Debian Jessieで、すべて異なるHWでチェックされています。
(おそらく)カーネルがデータをバッファリングしていることがわかりました。なぜなら、10分後にデバイスを再接続すると、すべてのデータが一度にフラッシュされるからです。私はこれが短い切断のために良いことを理解しています、私は10秒、15秒、または1分で問題はないでしょうが、15分はあまりにも多くです。
同様の質問は私の場合は不可能なアプリケーションプロトコルを実装することによって答えられました。 私はちょっと妥当な時間に相手側がパケット(TCP ACK)を取得したことを確認したいだけです。 socket.setsockopt
についてのドキュメントを慎重に読んでいますが、何も役に立たなかったまた、いくつかの回避策を実行するために送信バッファがフラッシュされたかどうかをチェックする方法を見つけられませんでした。
TCPキープアライブは、非アクティブな時間に基づいており、送信データがアクティビティであるため、いずれかを助けていません。