APRS Tier2 Network, T2FUKUOKA, KetaiTracker
JF6LZE, Munakata Fukuoka JAPAN, fukuoka.aprs2.net, f.aprsjp.net
 

APRSJAGATE, APRS Japanese Message Gateway Project

1. APRS Japanese Message Gateway (Filter)

APRSのメッセージ機能で日本語(とりあえずカナ)を使いたい。 しかし、APRSは世界につながっているシステムなので、日本固有のデータはトラブルの元になるかもしれないので、 流せない。さぁ、どうしましょう!?

FWD-NET時代は、日本語を普通に使っていましたが、転送先を@JPNに限定することで海外にマルチバイトが流れるのを防いでいましたけど...。

ということで、本 APRS Japanese Message Gateway の出番です。

2. 概念/原理

原理は簡単です。 日本語を使用しないクライアントが緑、日本語(マルチバイト)を使用するクライアントは赤とします。 それぞれ別のサーバに接続します。一番右の赤のサーバから上流(upstream)にデータを送るとき、マルチバイトを含んだデータは削除(ブロック)し、マルチバイトを含まないデータはそのまま通過させます。 これにより、マルチバイトを含んだデータが世界中のCore,T2サーバを含め一般のAPRSクライアントに到達しません。

流れ メッセージなど 結果
Ascii 通過
Ascii 通過
マルチバイト(カナ) 遮断
Ascii 通過(Filterを介さない)
マルチバイト(カナ) 通過(Filterを介さない)

APRSクライアントの接続先設定については Usageを御覧ください。

2-1. jagateを越えるマルチバイトのメッセージ交換は不可能

クライアントが増えてくると一台のサーバでは負荷が大きくなるので、サーバを増やさなければなりません。

上記のようなトポロジーの場合、はマルチバイトのメッセージ交換はできません。 マルチバイトを含まない場合は、gateway(filter)を通過しますので、メッセージの交換は可能です。

2-2. 理想的なトポロジー 1

のような接続ができれば、いいのですが.... javAPRSSrvrの場合、それらしき接続が可能なような気がするのですが、詳細はわかりません。 4つのAPRS CORE サーバはそれぞれ「横つながり」(sibling)で接続されているようなので、たぶん上記のような接続がなんらかの方法で可能なのかもしれません。

2-3. 理想的なトポロジー 2

結局、現状では、このような形になってしまうのかと思います。ただし最上位のが死んでしまうと.....

2-4. 理想的なトポロジー 3 (将来的な gatewayの機能)

リスクを分散/低減するには経路は複数必要です。 しかし、先に書いたようにこのままではマルチバイトのメッセージが通りません。 そこで、Gateway間でバイパスを作成します。 具体的には、

  • Gateway間でTCPセッションを別途張って、マルチバイトのメッセージを交換する。 だだし、gateway同士で互いに相手の存在を設定しておく必要がある。
  • APRSのUser-Defined Data Format を使って、APRSのプロトコルでメッセージを交換する。 ただし、User-Defined Data Formatも Printable Asciiと定義されている。 マルチバイトはそのまま通せないのでASCIIにエンコードしてから送信し、 受信したgatewayでマルチバイトに戻して下位のAPRS-ISに流す。 マルチバイトからASCIIにエンコードすると文字長が増えるので、この処理も必要。

一応、この機能を考えていたので今回作成したプログラムを filter とせずに gateway としています。