4Dのクライアント／サーバーアーキテクチャにおいて、ネットワークの信頼性は常に最優先事項でした。4D 21 R4では、これをさらに一歩前進させました。リモート上の4Dアプリケーションは、ユーザーのセッションを終了させたり、手動での操作を必要としたりすることなく、一時的なネットワーク中断にもシームレスに対応できるようになりました。

解決すべき課題

ネットワーク障害は、実環境での導入において避けられない現実です。4Dクライアントワークステーションと4Dサーバーの間には、多くのネットワークデバイス（スイッチ、ルーター、ファイアウォール、 VPNゲートウェイなど）が多数存在し、そのいずれかによって、2つのピアが一時的に互いに到達不能になる可能性があります。例えば、スイッチの再起動、ケーブルの抜き差し、経路上のどこかで発生する一時的なルーティングの問題などが挙げられます。こうした事象は通常、数分間しか続きませんが、それでもピア同士が互いに到達不能な状態になることがあります。

仕組み

この機能は、4Dのクライアント／サーバー通信を支えるQUICトランスポート層に基づいて構築されています。 QUICは本質的にコネクションレス（UDP上で動作）であるため、セッションを切断することなく、ピア間の通信が途絶えている期間を自然に許容できます。4D Serverがリモートの4Dアプリケーションに到達できなくなったことを検出した場合、セッションを直ちに終了させることはなくなります。代わりに、セッションを維持したまま、通信が再開されるのを待ちます。

この待機期間の長さは、新しいデータベースパラメータ「QUIC セッションタイムアウト」（セレクタ 135）によって制御されます。デフォルトは900 秒（15 分）で、最小値は 60 秒です。この設定はサーバー側で行い、その時点以降に開かれるすべての新しいセッションに適用されます。

// Read the current timeout value
$previousTimeout:=Get database parameter(QUIC session timeout)
// Set a custom timeout window of 10 minutes

SET DATABASE PARAMETER(QUIC session timeout; 600)

注：この値を変更しても、新しいセッションにのみ影響します。既存のセッションは、開始時に割り当てられた値を維持します。

ピアが到達不能になった場合の動作

unreachableSince サーバー側では、QUICレイヤーがリモートの4Dアプリケーションに到達不能であると報告するとすぐに、サーバー管理ウィンドウにその4Dクライアントが「到達不能」状態として表示されます。セッションは維持され、到達不能な4Dクライアントに対応する Process activity.sessions[] オブジェクトに、到達不能な4Dクライアントに対応する新しい 属性が利用可能になり、最後の通信から経過した秒数をカウントします。

// On the server — inspect all remote sessions
$processActivity :=Process activity(Sessions only)
For each ($session;$processActivity.sessions)
   If ($session.unreachableSince #Null)
LOG EVENT (Into 4D diagnostic log;"Remote "+$session.systemUserName+\
" unreachable for "+String($session.unreachableSince)+"s";\
Information message )
   End if

End for each

クライアント側では、Session.info.unreachableSince 属性が、サーバーとの最後の通信成功時から経過した秒数をカウントし始めます。「接続不可」の表示に切り替わるのは、サーバーとアクティブに通信しているウィンドウのみです。インターフェースはグレーアウトされ、状況に応じたメッセージが表示されます（小さなウィンドウではツールチップとしても表示されます）。 ローカルコードを実行しているウィンドウは影響を受けず、完全に使用可能な状態を維持します。ユーザーは、通信が復旧する間も、アプリケーションのオフライン部分での作業を継続できます。

// On the remote — check how long the server has been unreachable
If (Session.info.unreachableSince #Null)
ALERT ("Server unreachable for " +String(Session.info.unreachableSince) + "s")
End if

通信が再開された場合

QUIC セッションのタイムアウトが切れる前に通信が回復した場合、すべてが透過的に再開されます。

サーバー側では：

• サーバー管理ウィンドウでは、4D クライアントのステータスが「オンライン」に戻ります。
• unreachableSince 属性は、 Process activitysessions[] オブジェクトから削除されます。

クライアント側では：

• Session 、info 、unreachableSince の各属性が削除されます。
• 影響を受けたすべてのウィンドウは以前の状態に復元されます。

ユーザーは、何かが起こったことに気づかない場合もあります。

タイムアウトが超過した場合

ピア同士が定義されたタイムアウト時間より長く通信不能な状態が続いた場合、セッションは正常に終了します。

サーバー側では：

• 4D クライアント セッションが削除されます。
• 監視の目的で、診断ログに警告エントリが記録されます。

クライアント側では：

• パレットダイアログに、サーバーに接続できなかったためセッションが終了した旨の説明が表示され、再起動または終了の選択肢が提示されます。
• システム通知も表示されるため、アプリケーションがバックグラウンドにある場合でもユーザーに通知されます。アプリケーション名とアイコンは、アプリケーションのビルド時に定義されたものが使用されます。
  

これにより、最悪の場合でも、ユーザー体験がスムーズで、必要な情報が確実に伝わるようになります。

実際の動作をご覧ください

以下の動画では、その全容を解説しています。まず、ServerNet を使用した従来の動作（中断が発生すると即座にセッションが終了する）から始まります。その後、2つのシナリオにわたって新しい QUIC の動作を実演しています：

• 通信が中断され、タイムアウト期間内に復旧する場合。
• 通信が再度中断され、今回はタイムアウト時間を超過したためセッションが終了する。

これにより、ユーザーにとって多くの利点があります

コーディングは不要です。導入のための設定も必要ありません。4D 21 R4にアップグレードするだけで、すべての4Dクライアントユーザーに対し、この動作がすぐに利用可能になります。

これは単なるマイナーな改善ではありません。4Dクライアント／サーバー環境において、最も顕著かつ長年にわたる課題の一つを解決するものです。お客様からはこの点について不満の声が上がっていました。その悩みはこれで解消されます。

さらに、4Dは他社製品よりも一歩先を行っています。Webアプリケーションでは通常、ユーザーがサーバーへのアクセスを失ったことを示す表示がない（あるいは、それを実現するには多大な開発労力が必要）のに対し、4Dはこれを透過的かつ即座に処理します。影響を受けたウィンドウはグレーアウトされ、明確なメッセージが表示され、影響を受けていないウィンドウは動作を継続し、通信が再開されるとすべてが自動的に復元されます。 ローカルロジックとサーバー依存ロジックを適切に分離するようにソリューションが設計されていれば、ユーザーは追加の労力を一切かけずに、真にシームレスなオンライン／オフライン体験を実現できます。

これこそが、私たちがQUICに投資した理由です。詳細については、従来のネットワーク層から移行した理由に関する記事をお読みいただき、QUICの耐障害性を他のネットワーク層と比較したデモ動画をご覧ください。また、以前ご紹介したネットワーク層切り替え機能についても、さらに詳しく知ることができます。

この機能こそが、4D 21 R4 にアップグレードして QUIC を利用する大きな理由となります！

---

この機能についてご質問やフィードバックがございましたら、以下のコメント欄にご記入いただくか、4Dフォーラムまでお問い合わせください。