-
Notifications
You must be signed in to change notification settings - Fork 9
Closed
Description
Python client (net_sync_manager) lacks connection loss detection and reconnection
Summary
The Python client (net_sync_manager) has no mechanism for detecting, reporting, or recovering from a lost server connection. The C# (Unity) client has a full flow of OnConnectionError → StopNetworking → reconnect scheduling → StartNetworking, but the Python client has no equivalent.
Current behavior
- Receive loop error handling (
client.py:503-505): On exception, it logs an error and continues the loop as-is - Send errors: Returns
SendOutcome.fatal(), but callers must check the return value manually — there is no event notification - Server silence detection: No receive timeout or heartbeat monitoring, so a quietly disappeared server goes unnoticed
- Discovery:
start_discovery()broadcasts indefinitely, but there is no mechanism to restart it after a connection loss
Consequences
- When the server goes down, the receive loop continues spinning with broken sockets
- No error notification is delivered to the consumer
- No automatic recovery occurs
Comparison with C# client
| Feature | C# (Unity) | Python |
|---|---|---|
| Connection error notification | OnConnectionError event |
None (log only) |
| Reconnect scheduling | Delayed reconnect via _reconnectAt |
None |
| Socket teardown/recreation | StopNetworking → StartNetworking |
None |
| Discovery restart | Conditional restart in StartNetworking |
None |
| Receive timeout detection | None | None |
Suggested improvements
- Add a connection error event handler (
on_connection_error) - Implement reconnection logic with socket teardown and recreation
- Support discovery restart on reconnection
- (Both clients) Consider receive-timeout-based detection of server unresponsiveness
—-
Python クライアント (net_sync_manager) に接続断の検出・再接続機構がない
概要
Python クライアント (net_sync_manager) には、サーバーとの接続が切れた際の検出・通知・再接続の仕組みが存在しない。C# (Unity) クライアントには OnConnectionError → StopNetworking → 再接続スケジュール → StartNetworking という一連のフローがあるが、Python 側には対応する機構がない。
現状の動作
- 受信ループのエラーハンドリング (
client.py:503-505): 例外発生時にログを出力するだけで、ループはそのまま続行する - 送信時のエラー:
SendOutcome.fatal()を返すが、呼び出し側が戻り値を確認しなければ気づけない - サーバー無応答の検知: 受信タイムアウトやハートビート監視がないため、サーバーが静かに消えた場合に検知できない
- ディスカバリ:
start_discovery()は無期限にブロードキャストを送り続けるが、接続断後に自動で再開される仕組みはない
結果として起きること
- サーバーが落ちると、壊れたソケットのまま受信ループが空回りし続ける
- 利用者側にエラーが通知されない
- 自動復旧が行われない
C# クライアントとの比較
| 機能 | C# (Unity) | Python |
|---|---|---|
| 接続エラー通知 | OnConnectionError イベント |
なし (ログ出力のみ) |
| 再接続スケジュール | _reconnectAt による遅延再接続 |
なし |
| ソケット再作成 | StopNetworking → StartNetworking |
なし |
| ディスカバリ再開 | StartNetworking 内で条件付き再開 |
なし |
| 受信タイムアウト検知 | なし | なし |
対応案
- 接続エラー時のイベントハンドラ (
on_connection_error) の追加 - ソケット切断・再作成を伴う再接続ロジックの実装
- 再接続時のディスカバリ再開サポート
- (両クライアント共通) 受信タイムアウトによるサーバー無応答検知の検討
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
No labels