QNX RTOS：Qnet-透過的なネットワークインターワーキング

QNXリアルタイムオペレーティングシステムに関するメモサイクルの待望の継続を願っています 。 今回は、QNX独自のネットワークプロトコルであるQnetについてお話したいと思います。 ネイティブのQnetネットワークに加えて、QNXはTCP / IPプロトコルスタックをサポートすることをすぐに明確にします。これは、一般的にUnixライクなシステムの管理者に馴染みがあるはずです。 したがって、このノートでは、まずio-pktネットワーク管理者について少し説明し、次にQnetプロトコルについて詳しく説明します。 物語の過程で、4つの叙情的および1つの技術的脱線が私たちを待っています。

Qnetとは何ですか？

QNXネットワークは、相互接続されたターゲットシステムのグループであり、それぞれがQNX Neutrino RTOSを実行しています。 このようなネットワークでは、プログラムはすべてのノード（ノード、これはネットワーク上の個々のコンピューターの名前）上のリソースにアクセスできます。 リソースは、ファイル、デバイス、またはプロセス（別のノードでのプロセスの起動を含む）です。 同時に、ターゲットシステム（これらのノード）は、x86、ARM、MIPS、PowerPCなどのさまざまなアーキテクチャのコンピューターにすることができます（Qnetの現在の実装はクロスエンディアン環境でも機能します）。 しかし、これだけでは不十分であるように、修正なしでQNXに移植されたPOSIXアプリケーション（移植には再構築のみが必要な場合が多い）には、上記のQnetネットワーク機能があります。 興味をそそられて、これはどうやって起こるのでしょうか？

Qnetプロトコルは、メッセージングエンジンをQNX Neutrinoマイクロカーネルネットワークに拡張します。 そのため、Qnetの最大の秘密が明らかになりました。記事の後半で、これらすべてがどのように機能するかを見ていきます。

IO-PKTネットワークサブシステム

ネットワークサブシステムは、QNXサブシステムの1つの典型的な代表例です。 io-pkt*管理者（QNXリソースマネージャーテクノロジー上に構築）、デバイスモジュール（ドライバー）（ devnp-e1000.so 、プロトコルモジュール（ lsm-qnet.so 、およびユーティリティ（ ifconfigおよびnicinfoなど）でnicinfo 。 ちなみに、QNXにはio-pkt-v4 、 io-pkt-v4-hc 、およびio-pkt-v6-hc 3つのネットワークマネージャーがあります。 v4サフィックスは、このマネージャーがIPv4のみをサポートし、 v6バージョンがIPv4およびIPv6をサポートすることを示します。 サフィックスhc （高容量）は、暗号化とWi-Fiをサポートする高度なバージョンを意味します。 したがって、文献ではio-pkt*という名前を見つけることができますが、マネージャーio-pkt （アスタリスクなし）を呼び出します。 私たちの場合、この記事はQnetに関するものであるため、話しているTCP / IPのバージョンは関係ありません。




図 1. io-pkt詳細ビュー。

io-pktを図1に示します。 下位レベルには、有線および無線ネットワーク用のドライバーがあります。 これらはロード可能なモジュール（DLL、共有ライブラリ）です。 イーサネットに加えて、他の伝送メディアもサポートされていることに注意してください。 たとえば、ドライバーdevn-fd.so使用devn-fd.soと、ファイル記述子（fdは単なるファイル記述子です）を使用してデータの送受信を整理できるため、たとえばシリアルポートでネットワークを整理できます。 もちろん、速度は適切ですが、時にはそれが大いに役立ちます。 デバイスドライバーは、第2レベル（スタック）のマルチスレッドコンポーネントに接続されます。 スタックは、まず、ブリッジとリレーの機能を提供します。 第二に、スタックは統一されたパケット管理インターフェースとIP、TCP、およびUDPプロトコル処理を提供します。 最上位には、スタックとユーザーアプリケーション間でメッセージの受け渡しを実装するリソースマネージャーがあります。 関数open() 、 read() 、 write()およびioctl()ます。 libsocket.soライブラリは、 io-pktを、ほとんどの最新のネットワークコードの標準であるBSDソケットレイヤーAPIに変換します。

スタックは、イーサネットおよびIPレイヤー上のデータを操作するためのインターフェイスも提供します。これにより、DLLの形式で実行されるプロトコル（たとえば、Qnet）が必要なレベル（IPまたはイーサネット）に接続できます。 外部アプリケーションとの対話が必要な場合、プロトコル（たとえば、Qnet）には独自のリソースマネージャーが含まれる場合があります。 スタックには、ドライバーとプロトコルに加えて、BPF（バークレーパケットフィルター）とPF（パケットフィルター）のパケットフィルタリングが含まれています。

Qnetプロトコルをサポートしてio-pktを起動する例：

 io-pkt-v4-hc -d e1000 -p qnet 

-dオプションは、ネットワークコントローラードライバーdevnp-e1000.so指定し、 -pオプションはQnetモジュールをロードします。 実際、インストールディスクからQNXをインストールすると、ネットワークは起動スクリプトから自動的に起動します。通常、QNXを埋め込み、システムの起動速度を下げる場合は、手動で起動する必要があります。

イーサネットフレームの使用に加えて、QnetはIPパケットにカプセル化することもできます。 これは、たとえば分散ネットワークで作業する場合に便利です。 この場合のオーバーヘッドコストが増加することに留意してください。 Qnet over IPの実行例：

 io-pkt-v4-hv -d e1000 -p qnet bind=ip,resolve=dns 

何らかの理由でio-pktがQnetサポートなしで起動された場合、 lsm-qnet.soモジュールは後でlsm-qnet.soできます。次に例を示します。

 mount -Tio-pkt lsm-qnet.so 

io-pktに関するより完全な情報はQNXヘルプシステムで取得できます。記事のメイントピックに進みます。

Qnetはどのように機能しますか？

ユーザーの観点から見ると、Qnetは完全に透過的に動作します...停止します。 しかし、この文脈で単語の意味を透過的に明らかにする時ですか？ おそらくそれは時間です。 私たちの場合、透明性という用語は、リモートリソースへのアクセスに、ローカルリソースへのアクセスと比較して追加のアクションが必要ないことを意味します。 以下の例を使って説明します。

Qnetを起動すると、ディレクトリ/ネットが作成されます。これにより、各ネットワークノードのファイルシステムが、ノードの名前で個別のディレクトリに表示されます。 ホスト名（ホスト名）が設定されていない場合（つまり、デフォルト名はlocalhost）、/ netディレクトリでは、MACアドレスで構成される名前と呼ばれます。 たとえば、次のコマンドは、zvezdaノードのルートディレクトリの内容を表示します。

 ls -l /net/zvezda 

次のコマンドを使用すると、zvezdaノードの起動スクリプトの1つを編集できます。

 vi /net/zvezda/etc/rc.d/rc.local 

整理されたファイルへのアクセスにより、ここで異常なことは何もありません。 デバイスへのアクセスも同様に機能します。 そのため、たとえば、別のノードのシリアルポートで作業できます。

 qtalk -m /net/zvezda/dev/ser1 

そして、より興味深い例を次に示します。

 phcalc -s /net/zvezda/dev/photon 

通常、Photonアプリケーション（これは標準のQNXグラフィカルウィンドウサブシステムです）では、接続先のサーバーを指定できます（オプション-s ）。 この場合、アプリケーションはローカルノードで実行され、zvezdaノードにグラフィックウィンドウが表示されます。 ローカルホストはグラフィックスサブシステムを実行する必要さえありません。 これは、ノードにグラフィックコントローラーがないが、センサーまたはシステムセットアップから収集されたデータのグラフィック表示が必要な場合など、場合によっては便利です。 また、このアプローチにより、グラフィックサーバーの中央処理装置をオフロードできます。


ファイルとデバイスについては、整理されたと思います。 しかし、プロセスはどうですか？ これでも、すべてが簡単です。 多数のシステムユーティリティが-nオプションを提供します。これは、リモートホストで作業するか、リモートホストから情報を収集する必要があることを示します。 たとえば、次のようなコマンドライン引数を使用して、実行中のプロセスのリストを取得できます。

 pidin -n zvezda arg 

一部のユーティリティまたはプログラムが-nオプションをサポートしていない場合、標準のユーティリティが-nます。これは、たとえば次のように別のノードでアプリケーションを実行するように設計されています。

 on -f zvezda ls 

この場合、 lsユーティリティはzvezdaホストで実行され、ユーティリティの出力は現在のターミナルに表示されます。


プロセスの停止も簡単です slayユーティリティは-nオプションをサポートしています。 例：

 slay -n zvezda io-usb 

同様に、 slayを使用すると、SIGTERMだけでなく、他の信号を送信できます。

Qnetはプログラマーの観点からどのように機能しますか？

前のセクションでは、RTOSユーザーの観点からQnetを検討しました。 ほとんどの場合、Qnetをサポートするためにソフトウェア開発さえ必要ありません。 これは本当ですか？ つまり ネットワークアプリケーションを作成するには、特別なフレームワークやライブラリを使用する必要はありませんか？ はい、必須ではありません。 POSIXを使用する場合、違いに気付くことすらありません。 しかし、根拠がないようにするために、小さなプログラムのコードを提供します。これは、例として文字列をファイルに保存します（リモートホストを含​​む）。

 #include <unistd.h> #include <stdlib.h> #include <stdio.h> #include <fcntl.h> int main(int argc, char *argv[]) { int fd; char str[] = "This is a string.\n"; if ( argc < 2 ) { printf("Please specify file name.\n"); exit(1); } if ( (fd = open(argv[1], O_RDWR|O_CREAT, 0644)) < 0 ) { perror("open()"); exit(1); } write(fd, str, sizeof(str)-1); close(fd); return 0; } 

このコードはQnetと互換性があります。 結局のところ、行が/tmp/1.txt保存されるファイルと/tmp/1.txt保存されるファイルに違いはありません。 デバイスについても同じことが言えますが、プログラマ向けの2つのコードフラグメントは同一です（違いはファイル名のみです）。

 fd = open("/dev/ser1", O_RDWR); 

そして

 fd = open("/net/zvezda/dev/ser1", O_RDWR); 

ネットワークでの作業のこの単純さを可能にするものは何ですか？ open()などのPOSIX呼び出しは、 メッセージングを制御する一連の低レベルのマイクロカーネル呼び出しを生成します： ConnectAttach() 、 MsgSend()など。 ネットワークに必要なプログラムコードは、ローカルで使用されるものと同じです。 違いはパス名のみです。ネットワーク操作の場合、パス名にはホスト名が含まれます。 ホスト名の付いたプレフィックスはホスト記述子に変換され、後でConnectAttach()への低レベルの呼び出しで使用されます。 ネットワーク内の各ノードには、独自の記述子があります。 ファイルシステムパスの名前空間は、記述子の検索に使用されます。 1台のマシンの場合、検索結果はノード記述子、プロセス識別子、およびチャネル識別子になります。 Qnetネットワークの場合、結果は同じになり、ノード記述子のみがゼロ以外になります（つまり、ND_LOCAL_NODEと等しくなく、これはリモート接続を示します）。 ただし、これらの呼び出しはすべて非表示であり、単にopen()使用する場合はそれらを処理する必要はありません。

単純なopen()?関数の背後に隠されているものは何open()?

node1アプリケーションがnode2シリアルポート/dev/ser1を使用する必要がある状況を考えnode2 。 図 /net/node2/dev/ser1 2は、アプリケーションが/net/node2/dev/ser1という名前でopen()関数を呼び出したときに実行される操作を示してい/net/node2/dev/ser1 。



図 2. Qnetネットワークを介したメッセージング。

1. アプリケーションは、パス名/net/node2/dev/ser1への許可を求めるメッセージをローカルプロセスマネージャーに送信します。 なぜなら lsm-qnet.soは/net lsm-qnet.so担当し、プロセスマネージャーは、アプリケーションがローカルio-pktネットワーク管理者に連絡する必要があることを示すリダイレクトメッセージを返します。
2. アプリケーションは、パス名を解決するための同じ要求とともに、ローカルio-pktネットワーク管理者にメッセージを送信します。 ローカルネットワーク管理者は、 node2ノードマネージャープロセスのノード記述子、プロセス識別子、およびチャネル識別子を示すリダイレクトメッセージを返します。
3. アプリケーションは、 node2ノードプロセスマネージャーとの接続を作成し、パス名の解決要求を再度送信します。 node2のプロセスマネージャーは、ノード記述子、プロセスID、および自身のノード（ node2 ）のシリアルポートドライバーのチャネル識別子を示す別のリダイレクトメッセージを返します。
4. アプリケーションは、 node2シリアルポートドライバーとの接続を作成し、さらにメッセージングに使用できる接続識別子を受け取りnode2 （たとえば、 read() 、 write() 、および他のPOSIX関数が呼び出されたとき）。

このすべての探求の後、受信した接続識別子によるメッセージの交換は、ローカル交換の場合とまったく同じ方法で行われます。 それ以降のすべてのメッセージング操作は、 node1のアプリケーションとnode1のシリアルポートドライバー（また、通常のQNXアプリケーション）の間で直接実行されることが重要です。

POSIX関数open()を使用するプログラマーにとって、これらの低レベルの呼び出しはすべて隠されていることをもう一度強調します。 open()を呼び出すと、ファイル記述子またはエラーコードが返されます。

サービス品質ポリシー

Qnetプロトコルはマルチチャネル伝送をサポートしています。 複数のチャネルを使用するときに動作モードを選択するには、サービス品質（QoS）ポリシーが適用されます。 Qnetネットワークでは、QoSは基本的に伝送媒体を選択します。 ただし、システムにネットワークインターフェイスが1つしかない場合、QoSは機能しません。 次のサービス品質ポリシーがサポートされています。

• loadbalance-Qnetプロトコルは利用可能な通信チャネルを使用し、それらの間でデータ転送を分散できます。 このポリシーはデフォルトで使用されます。 このモードでは、ノード間のスループットは、使用可能なすべてのチャネルのスループットの合計に等しくなります。 チャネルの1つが壊れると、Qnetは他の使用可能なチャネルを使用するように自動的に切り替わります。 サービスパケットは障害が発生したチャネルに自動的に送信され、通信が回復すると、Qnetはこのチャネルを再び使用します。
• 優先 -指定された1つの通信チャネルのみが使用され、残りはメインの通信チャネルが失敗するまで無視されます。 メイン通信チャネルに障害が発生すると、Qnetは使用可能なすべてのチャネルを使用して負荷分散モードに切り替わります。 メインチャネルを復元すると、Qnetは優先モードに切り替わります。
• 排他的 -指定された1つの通信チャネルのみが使用され、メインのチャネルが失敗しても残りのチャネルは使用されません。

チルダ文字（〜）で始まるパス名修飾子を使用して、サービス品質ポリシーを設定します。 たとえば、 en0インターフェイスでQoS 専用ポリシーを使用してzvezdaホストのシリアルポートにアクセスする場合、名前は次のようになります。

 /net/zvezda~exclusive:en0/dev/ser1 

Qnetを使用する場合

プロトコルの選択は多くの要因に依存します。 Qnetプロトコルは、QNX Neutrino RTOSを実行し、同じバイト順の信頼できるコンピューターのネットワークを対象としています。 Qnetはリクエストを認証しません。 アクセス権は、通常のユーザー許可とファイルグループによって保護されます。 Qnetプロトコルも接続を確立するプロトコルであり、ネットワークエラーメッセージがクライアントプロセスに送信されます。

異なるオペレーティングシステムを搭載したコンピューターがネットワークで動作する場合、またはネットワークの信頼度が高くない場合は、QNXでも動作する他のプロトコル、たとえばTCP / IP、特にFTP、NFS、Telnet、SSHなどの使用を検討する価値があります。

エピローグの代わりに

もちろん、このノートでは、すべてのQnet機能と機能が考慮されているわけではありませんが、プロトコル機能の一般的な説明が記載されています。 QnetまたはQNXテクノロジー全般に興味がある場合は、QNX Neutrinoのシステムアーキテクチャのこれらのトピックおよびその他のトピックに関する資料を参照してください。 ドキュメントは、Webサイトwww.qnx.com （英語）から電子形式で入手できます。一部の翻訳は、Webサイトwww.kpda.ruから入手できます。 印刷物にはロシア語の翻訳もあります。

リアルタイムオペレーティングシステムQNX Neutrino 6.5.0システムアーキテクチャ。 ISBN 978-5-9775-3350-8
リアルタイムオペレーティングシステムQNX Neutrino 6.5.0ユーザーガイド。 ISBN 978-5-9775-3351-5