v19r7以降,Webサーバーにアクセスするとステータスコード429
Too many requestsが返されることがあります。これは,Webサーバーを外部に公開するライセンスがインストールされていない場合に返されるエラーです。
v19r3以降,4Dには,OAuth2認証を容易にする4D Netkitコンポーネントがプリインストールされています。OAuth2認証は,Microsoft 365のようなWebサービスで採用されています。Microsoft 365の場合,POP3やIMAPプロトコルの 基本認証が廃止されたことに伴い,ユーザー名とパスワードによるログインができなくなりました。
OAuth2認証をするためには,Webサービスのプロバイダーからトークンと呼ばれる情報を受信するためにWebサーバーを開始する必要があります。4D Netkitも例外ではなく,OAuthトークンを受信するためにコンポーネントのWebサーバーを利用しています。クライアント側でOAuth2認証するためには,クライアント側のWebサーバーを使用します。
v19r7以降,4D NetKitでWebサービスのOAuth2認証ができるようにするため,Webサーバーを外部に公開するライセンスがインストールされていなくても,1
分間に数回の制限内でHTTPリクエストが処理できるよう,仕様が見直されています。この状況でWebサーバーを外部に公開することはライセンスで許可されていません。限度を超えたリクエストを受け付けた場合,サーバーはステータスコード429
Too many requestsを返します。
v20では,クライアント/サーバー通信テクノロジーのアップグレードが計画されています。次世代のネットワークレイヤーは,現在公開中のベータ版で試験的に有効にすることができ,v20 LTS(Long Time Support)の正式リリースでは全面的に無効化され,v20 Rバージョンで選択的に有効化できるようになります。その後,v21で標準のネットワークレイヤーが切り替わる予定です。
この記事では,次世代ネットワークレイヤーについて説明します。
初期の4D Serverは,ネットワークコンポーネントをインストールすることにより,IPX/SPX・TCP/IP・ADSPいずれかのネットワークプロトコルで4D Clientから4D Serverに接続することができました。4D Client以外のアプリケーションから4D Serverに接続するための4D Openも同じネットワークコンポーネントを使用します。その後,v2003ではプロトコルがTCP/IPに一本化され,本体に組み込まれたことにより,コンポーネントを別途インストールする必要がなくなりました。
v11 SQLでは,Unicodeモードや同時接続クライアント数の増加といった課題に対応し,通信レイテンシーをできるだけ抑えるため,TCP/IPネットワークレイヤーが全面的に新しくなりました。この世代のネットワークレイヤーは,下記のような特徴を備えています。
19813
,後者は19814
クライアントがサーバーに接続すると,通信用の主要なソケットを維持するためのアプリケーションプロセス Main process がクライアントとサーバーの双方で作成されます。同じようにクライアントが新規プロセスを起動し,サーバーにアクセスしようとすると,適宜,サーバー側にもユーザープロセスが作成されます。終了したプロセスはTCP接続を再利用できるようにしばらくプールされますが,やがて破棄されます。なお,クライアントがサーバーに接続すると,サーバーからクライアントにメッセージを送信するためのクライアント管理プロセス Client manager process も作成され,専用のソケットが開かれます。クライアントは内部タイマープロセス Internal timer process でこのソケットを定期的にチェックします。アプリケーションサーバーとは,ユーザー認証・リソース管理・ストアドプロシージャー・命名セレクション・セット・サーバー側プロセス変数に対するアクセス・サーバー管理・デザインモードのオブジェクトロックなど,全般的なクライアント/サーバー通信に使用されるプロセス群の総称です。
今では旧式ネットワークレイヤーと呼ばれるこのテクノロジーは,従来のクライアント/サーバーと比較した場合,TCPパケットのサイズがおおきく,数つまり頻度が少ない傾向にあります。細かい設定は,データベースパラメーターつまりデータベース設定で調整することができます。特に重要なのはクライアント/サーバーの接続タイムアウトです。
クライアントは,タイムアウトの1/3
が経過するたび,いわゆる ping を送信します。サーバーとの通信に失敗した場合,ネットワーク接続に障害が発生したものと判断し,エラーが返されます。
上記のタイムアウトはクライアント/サーバーアプリケーションの通信つまりポート番号19813
に適用されます。データアクセスには適用されません。19814
ポートのソケットは常に開かれた状態であることが前提なので,ルーター機器などが無活動のソケットを閉じるようになっている場合,しばらくのアイドル時間を経てからクライアントがサーバーのデータベース(DB4DまたはSQL)にアクセスするとエラーが返される恐れがありました。アイドル時間タイムアウトは,データベースパラメーターで調整することができます。
v15では,旧式ネットワークレイヤーの弱点を克服し,スリープ検出やシングル・サイン・オン(クライアントはログイン画面を表示せず,Windowsのログインアカウントでサーバーに接続する)といった要望に応えるため,改良されたTCP/IPネットワークレイヤーが利用できるようになりました。ServerNetとも呼ばれる新ネットワークレイヤーを有効にすると,さまざまな先進的な機能が利用できるようになります。
新ネットワークレイヤーでは,前述したデータベース設定に関係なく,クライアント/サーバーの接続タイムアウトが「なし」となります。
ServerNetは,当初,Mac 64-bit版では必須,Windows 32-bit版では任意のデータベース設定でしたが,v17以降,Mac 64-bit版でも旧式ネットワークレイヤーが選択できるようになりました。
旧式ネットワークレイヤーは豊富な実績があり,長年,世界中の4D Serverで使われてきましたが,1
個の接続に要するスレッド数が多く,全体として多くのメモリを消費する設計でした。たとえば,サーバー側で1000
プロセスを管理するためには4000
以上のスレッドが必要です。コンテキストを切り替えたり,メモリを確保したり,スレッドを作成したりするたびに多少の遅延が発生します。特にv11からv13のMac版は32-bitアプリケーションゆえに利用できるメモリが限られていたため,サーバー側のプロセススタックを少しでも節約できるよう,データベースパラメーターが用意されました。
旧式ネットワークレイヤーは長年の保守によって高度に複雑化し,大規模なシステムだけで発生するような特殊な現象を調査することが困難な状況になりつつあったので,v14のRバージョンではすっきりした設計の新ネットワークレイヤーが開発され,漸進的に改良されることになりました。
新ネットワークレイヤーは,軽量かつ高性能を目指して開発されましたが,処理の内容次第では,旧式ネットワークレイヤーのほうがパフォーマンス面で優れていることがあります。とはいえ,旧式ネットワークレイヤーよりも詳細な診断ログを記録するように作られていることも手伝って,バージョンを追うごとに安定性と速度が向上し,v19のRバージョンでは,非常に高い完成度に到達しました。
では,なぜ再びここでネットワークレイヤーを見直すことになったのか,と疑問に思うかもしれません。
上述したように,4Dのネットワークレイヤーは,初代(v3からv2004)・旧式(v11からv15)・ServerNet(v15からv19)いずれもTCP/IPプロトコルをベースに4Dが独自に開発したものです。一方,業界ではTCPを使用しない,QUICが注目を集めています。
4Dデベロッパーの頭を悩ませてきたエラー(ヌル終点・接続エラーなど)のほとんどは,TCPソケットの仕様から切り離せないものです。そのため,不安定なネットワーク環境でも簡単には切れないクライアント/サーバー環境を構築するために実績の豊富なQUICが4Dのネットワークレイヤーに採用されることになりました。ServerNetと同じように,段階的に改良を重ねられるよう,移行期間が設けられます。
QUICはネットワーク障害に強く,TLS 1.3以上の暗号化で保護されていながら,効率的で高速である,という特徴を有しています。これまでのように4D側で複数のポート番号と多数のソケットを開いたままにして使いわけるのではなく,単一のUDPポート(やはり19813
)を介してすべての通信をするというシンプルな設計も魅力です。v20のベータ版ではQUICネットワークレイヤーをプレビューすることができますが,運用では安定したServerNetを使用することが推奨されています。v20のLTSでQUICが無効化されるのはそのためです。QUICネットワークレイヤーは,v20のR3ないしR5から利用できるようになる見込みです。
関連記事:
V20 QUIC network layer: a successor to the “New” Network layer
VP Convert from 4D View
は4D Viewプラグインで作成したドキュメントをView Proスプレッドシートに変換するコマンドです。フィールドに対する単純な参照は対応するView Proスプレッドシートのフォーミュラに変換されますが,文字列とフィールドを組み合わせたフォーミュラは変換されません。これは仕様です。
ハイライトボタンは,バイナリモードにだけ存在する旧式のフォームオブジェクトです。ハイライトボタンが配置されたフォームをプロジェクトモードに変換した場合,ハイライトボタンは透明ボタンになります。ボタンにヘルプTipsが設定されている場合,自動的に On Mouse Move イベントが有効となることにも留意してください。透明ボタンは画面にレンダリングされないため,ヘルプTipsを表示するためにはマウス移動イベントを有効にする必要があります。これは仕様です。
Mac版の4D v19は,Universal 2バイナリ形式で提供されており,x86_64とApple Silicon(ARMアーキテクチャ)のどちらでもインタープリター版のストラクチャをネイティブアプリとして実行することができます。
4DのコンパイラーはIntel(AMDアーキテクチャ)のコードを生成するように設計されていますが,MacにXcodeがインストールされていれば,メソッドのソースコードを clang コンパイラーに生成させることにより,Apple Siliconターゲットのアプリケーションをビルドすることもできます。
clang コンパイラーを利用してApple Siliconターゲットのコンパイルが実行できるのは,プロジェクトモードだけです。バイナリモード,つまり .4DB というファイル拡張子を持つストラクチャファイルをXcodeでコンパイルすることはできません。
互換性のために残されているバイナリモードでアプリケーションを開発している場合,データベースをプロジェクトモードの変換するか,IntelターゲットのアプリケーションをビルドしてRosetta 2で4Dを起動するか,コンパイルせずにインタープリターモードでアプリケーションを運用するか,よく検討した上で決定することになります。一旦,変換したストラクチャをバイナリモードに戻すことはできません。
初期の4Dはコンパイルすることにより大幅な速度の向上が望めましたが,現在ではインタープリターモードでも快適に動作しますので,さほどパフォーマンスに差はないと考えられています。
4DはRosetta 2でサポートされていない特殊な実行ファイルではありませんが,AppleはRosetta 2トランスコーダーの詳細を公開していないため,RosettaモードでIntelやApple SiliconネイティブのMacと違う振る舞いをする可能性がないとは言えません。問題があるとすれば,浮動小数点演算など,CPUに対する直接的な命令の実行でしょう。たとえば,4Dで0
による整数除算(%
演算子)を実行した場合,通常はエラーが返されませんが,Rosettaコンパイルモードではエラーが返されます。0
による除算は正しい結果が定義されていないので,Rosettaの実装による違いであり,4Dの不具合ではありません。なお,コンパイルの対象となる演算子を記述せず,同等の演算をするMod
関数を実行すれば,インタープリターモードと同じ振る舞いになります。これは仕様です。
論理積演算子と比較演算子が併用された場合,左から右に向かって式が評価されます。演算子の種類による優先順位はありません。これは仕様です。たとえば
$boolean:=False
$text:="foo"
$result:=$text="" && $boolean=False
のようなコードを実行した場合,False
ではなくTrue
が返されます。
$result:=(($t="") && ($b=False))
$result:=((($t="") && $b)=False)
左から右に向かって式が評価されるため,論理積演算ではなく,False=False
という比較演算になっている点に注目してください。こうしたエラーを避けるため,明示的ばカッコを記述することが勧められています。
エンティティセレクション型のリストボックス列にThis.relatedEntity.objectAttribute.property
のようにリレーション属性とオブジェクト記法を組み合わせたORDAパスを記述した場合,ヘッダークリックによる並び替えで属性”objectAttribute.property”が見つからないというエラーが返されます。これは仕様です。ヘッダークリックによる並び替えは内部的にorderByFormula()
ではなくorderBy()
を実行しています。
純粋なORDAパスではなく,フォーミュラがデータソースに設定されているリストボックス列の並び替えは On Header Click イベントで実装する必要があります。
ペーストボードの管理で説明されているように,Pasteboard data size
は,下記のデータタイプ識別子をサポートしています。
上記に加え,TEXT
PICT
などの4文字識別子が「以前のバージョンの4Dとの互換性のために」残されています。TEXT
つまりText data
定数は,UTIのcom.apple.tradional-mac-plain-text
を指している点に留意してください。コピー元のアプリケーションがこのタイプのデータをペーストボードに転写していない場合,Pasteboard data size
は-102
つまり「データなし」を返します。これは仕様です。