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

解決すべき課題

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

仕組み

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

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

// カレントのタイムアウト値を読み出す
$previousTimeout:=Get database parameter(QUIC session timeout)
// 10分のカスタムのタイムアウトを設定する

SET DATABASE PARAMETER(QUIC session timeout; 600)

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

ピアが通信不能になった場合の動作

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

// サーバー上 — 全てのリモートセッションを検査する
$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 属性が、サーバーとの最後の通信成功時から経過した秒数をカウントし始めます。”通信不能”の表示に切り替わるのは、サーバーとアクティブに通信しているウィンドウのみです。インターフェースはグレーアウトされ、状況に応じたメッセージが表示されます(小さなウィンドウではツールTipsとしても表示されます)。 ローカルコードを実行しているウィンドウは影響を受けず、完全に使用可能な状態を維持します。ユーザーは、通信が復旧する間も、アプリケーションのオフライン部分での作業を継続できます。

// リモート(クライアント)側 — どのぐらいサーバーと通信不能になっているかをチェックする
If (Session.info.unreachableSince #Null)
ALERT ("サーバーと" +String(Session.info.unreachableSince) + " 秒間通信ができていません")
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フォーラムまでお問い合わせください。