5. アプリケーションプロトコルの概要

それぞれのアプリケーションプロトコルは他と区別できるようにユニークなプロトコル ID を持っています。将来のデバイスは新しいデータ型を転送するための追加のプロトコルを導入したり、既存プロトコルの改訂版を提供するかもしれません (例えばプロトコル A101 はプロトコル A100 の改訂版として導入されるかもしれません)。新しいプロトコルが導入される時は必ずホストソフトウェアが新しいプロトコルに対応するためにアップデートされなければならないと予想されます。しかし、新しいデバイスは以前のプロトコルのいくつかをサポートし続けるかもしれないので、以前のソフトウェアでも完全または部分的に通信可能かもしれません。この能力をよりうまくサポートするために、新しいデバイスはそれらがサポートしているプロトコルをホストに報告する事が出来ます (6.2章参照)。さもなくば、ホストはデバイス型に対してどのプロトコルが使用されているかを決定するための検索テーブルを含まなければいけません (8.2章参照)。

5.1 ドキュメントされていないアプリケーションパケット

デバイスはこの仕様で文書化されていないパケット ID を含んだアプリケーションパケットを送る可能性があります。これらのパケットは内部テストの目的で Garmin の技術者によって使用されます。これらの内容はいつでも変更の可能性があるため、いかなる目的でもサードパーティアプリケーションで使用すべきではありません。それらはこの仕様で記述される物理プロトコルでハンドルされ、破棄されなければいけません。

5.2 パケット順序

それぞれのアプリケーションプロトコルはパケット順序に基づいて定義されています。それらは二つのデバイス間で交換されるパケットのパケットの方向、パケット ID、パケットデータ型を含む順序と型を定義しています。パケット順序の例を以下に示します:

この例では交換される 5 つのパケットが存在し、3 つは Device1 から Device2 へ、2 つは反対の方向です。これら 5 つのパケットは応答 (acknowledge) されなければいけませんが、明快さのため応答パケットはテーブルから省略されます。大部分のプロトコルは対称型です。ある方向へ転送するためのプロトコル (例えばホストからデバイスへ) は他方へ転送するためのプロトコル (例えばデバイスからホスト) と同じ意味を持ちます。対称型のプロトコルに対して、デバイスまたはホストは Device1 または Device2 の役割を担います。非対称型のプロトコルに対して、順序テーブルでは Device1, Device2 を示す代わりにデバイスとホストの役割を明確に示しています。

テーブルの最初の列はパケット番号を表しています (参照のために使用されるだけでこの番号はパケットには埋め込まれません)。2 列目はそれぞれのパケットの移動方向を示します。3 列目はパケット ID 列挙名を示します (パケット ID の実際の値を知るには 3.2.3章を参照してください)。最後の列はパケットデータ型を示します。

5.3 パケットデータ型

パケットデータ型はいくつかの方法で表記されています。第一に、明確な名前を付けられたデータ型 (例えば "First_Data_Type") として指定されます。明確な名前を付けられたデータ型は全てこの文書で定義されています。第二に、パケットデータが使用されていない事を示します (例えば "ignored")。この場合、パケットデータは 0 バイトのサイズとなります。最後に、パケットに対するデータ型に角括弧表記 (例えば <D0>) を使用した指定です。この表記方法はデータ型がデバイス固有であることを示します上記の例ではデバイス固有のデータ型が 3 つ (<D0>, <D1>, <D2>) 存在しています。

これらのデバイス固有のデータ型は、現在接続されているデバイスのタイプに依存するホストによって動的に決定されます。古いデバイスに対してのこの決定はホストに検索テーブルを持たせる事によってなされます (8.2章参照) が、新しいデバイスは動的のそれらのプロトコルとデータ型を報告する事が出来ます (6.2章参照)。

5.4 パケットの標準的な開始と終了

多くのアプリケーションプロトコルはそれぞれ Pid_Records, Pid_Xfer_Cmplt と呼ばれる以下の表に示すような標準的な開始と終了のパケットを使用します:

最初のパケット (パケット 0) は続くデータパケットの数から Pid_Xfer_Cmplt を除外した数を Device2 に示します (パケット 1 から n-2)。これにより Device2 は転送の進捗状況を監視できるようになります。最後のパケット (パケット n-1) は転送が完了したことを示します。この最後のパケットも転送のどれが完了したかを示すためのデータを Pid_Xfer_Cmplt に含んでいます (6.3章参照)。

転送のそれぞれに対する Command_Id_Type 値は転送それぞれを開始するために使用したコマンド ID と一致します (6.3章参照)。結果的に、実際の Command_Id_Type 値はデバイスがどのデバイスコマンドプロトコルを実装しているかに依存します。この依存性のため、この文書では Command_Id_Type に対する (値ではなく) 列挙名を用いて後述のアプリケーションプロトコルそれぞれで説明しています。

5.4.1 Records_Type

Records_Type は続くデータパケットの数から Pid_Xfer_Cmplt を除いた数を示す 16 ビット整数です。この Records_Type に対する型定義は以下のように表されます:

typedef uint16 Records_Type;

5.5 名前で識別されるデータのデバイス側での上書き

ホストからデータを受け取る時、いくつかのデバイスは名前で識別されるデータを消去し、ホストから受信した新しいデータをそこへ配置するでしょう。例えばホストが XYZ と名付けられたウェイポイントを送信すると、デバイスはデバイスのメモリに保存されている XYZ と名付けられていた以前のウェイポイントを上書きします。名前で識別されるデータを上書きする前にデバイスから警告は送信されません。

そのほかのデバイスは名前で識別されるウェイポイントに対して特別な扱いを行います。例えば、これらのデバイスは到着したウェイポイントと既存のウェイポイントの位置を比較する事が出来ます (注意:比較に高度は考慮されません)。位置が同じであればデバイスは同じ名前の既存のウェイポイントを消去しホストから受け取った新しいウェイポイントと入れ替えます。位置が異なるなら、デバイスは受け取ったウェイポイントに対して新しいユニークな名前を作成して既存のウェイポイントをそのまま残すでしょう。デバイスがウェイポイントを扱う方法 (上書き vs. ユニーク名) をホストから知る有効なメカニズムはありません。