（その２）で書いた問題点が分かってきた。
例えばWin10にUSER1でサインインし、そのままシャットダウンする。その後再度PCを立ち上げAdministratorでサインインする。このときタスクマネージャでユーザを見ると何故かAdministratorの他にUSER1もサインインしている。だからAdministratorをシャットダウンしようとすると「他に使用中のユーザがいる」と言われてしまう。
つまりサインアウトした筈のUSER1がシャットダウン後もゾンビのように生きているんだ。当然USER1のシステム関係のファイルは使用中になり削除できない。じっさいUSER1をシャットダウン、Shift+シャットダウン、再起動の何れで止めても、再度PCを立ち上げるとUSER1はゾンビのようにサインインしている。
色々やった結果、USER1ゾンビを成仏させるには USER1でサインイン中に「サインアウト」をやるしかない事がわかった。
やはりWindows10 1803からこの現象は出始めたようなので、1803で仕様が変わったのだろう。OneDriveを生かすための変更だと思う。勝手に仕様変更し新機能を押し付けてくるMSのいつもの独善的なやり方だから驚かないが、とっても頭にくる。
【その後・・・】
ネット情報によるとこの現象は1709から導入された機能のようで、うちでは1803から顕在化した。さらに次のように設定することで防げることが分かった（ユーザごとの設定が必要）。
・「設定」→「アカウント」→「サインインオプション」→「サインイン情報を使用してデバイスのセットアップを自動的に完了し、更新または再起動後にアプリを再び開くことが出来るようにします」を【OFF】にする。
しかしこの設定の意味や副作用を理解・説明できる人はいないだろう。またうちのようにリモートで多くのアカウントを管理している場合は個別にサインインが必要なこの設定方法は使えない。
2018年11月28日水曜日
2018年11月15日木曜日
ゾンビのようなOneDrive（その２）
OneDriveがまたやってくれた。
Windows10上のアカウントをリモートで管理しているが、アカウントを削除できないんだ。
Fall Creators Update(1709)まではうまく行っていたんだがApril 2018 Update(1803)になってから時々原因不明のエラーが出て終わるようになった。
削除手順はアカウントの削除、フォルダの削除、レジストリの削除を行うんだがユーザの一部ファイル（複数）へのアクセスが拒否され、フォルダの削除がエラーで終わる。当然削除できていない。
エラーメッセージを見るとユーザのAppDataフォルダ内のOneDrive関係ファイルが噛んでいるようだ。 たぶんOneDriveがユーザのドキュメントの変更を裏で監視していてCloudと同期をとっている（カラクリが生きている）んだろう。アカウントはすでに削除が済んでいるので再起動してやればフォルダを離してくれるだろう。うちではOneDriveは一切使っていないので何も問題ない筈だ。
再起動したら案の定、ユーザのフォルダはフリーとなり削除できた。しかしこれではリモートでの作業はできなくて、60台を作業するにはやたら手間がかかるうえに作業手順が幾つか増えた。
こういうのを小さな親切、大きなお世話と言うんだろうなぁ。
ネット情報もOneDriveの提灯記事ばかりで、OneDriveは便利でこれを使わない選択はあり得ないみたいな内容である。何なんだろうねぇ？
あと、前に報告したコンピュータ名の大文字小文字を区別するようになったのもLinuxなどWindows以外でもこのカラクリを使えるようにするため、つまり囲い込むための変更だった可能性があるなぁ・・・とっても迷惑なんだけど。
Windows10上のアカウントをリモートで管理しているが、アカウントを削除できないんだ。
Fall Creators Update(1709)まではうまく行っていたんだがApril 2018 Update(1803)になってから時々原因不明のエラーが出て終わるようになった。
削除手順はアカウントの削除、フォルダの削除、レジストリの削除を行うんだがユーザの一部ファイル（複数）へのアクセスが拒否され、フォルダの削除がエラーで終わる。当然削除できていない。
エラーメッセージを見るとユーザのAppDataフォルダ内のOneDrive関係ファイルが噛んでいるようだ。 たぶんOneDriveがユーザのドキュメントの変更を裏で監視していてCloudと同期をとっている（カラクリが生きている）んだろう。アカウントはすでに削除が済んでいるので再起動してやればフォルダを離してくれるだろう。うちではOneDriveは一切使っていないので何も問題ない筈だ。
再起動したら案の定、ユーザのフォルダはフリーとなり削除できた。しかしこれではリモートでの作業はできなくて、60台を作業するにはやたら手間がかかるうえに作業手順が幾つか増えた。
こういうのを小さな親切、大きなお世話と言うんだろうなぁ。
ネット情報もOneDriveの提灯記事ばかりで、OneDriveは便利でこれを使わない選択はあり得ないみたいな内容である。何なんだろうねぇ？
あと、前に報告したコンピュータ名の大文字小文字を区別するようになったのもLinuxなどWindows以外でもこのカラクリを使えるようにするため、つまり囲い込むための変更だった可能性があるなぁ・・・とっても迷惑なんだけど。
2018年10月26日金曜日
脅迫メールが来た
10月半ばから脅迫メールが来はじめた。
タイトルは「xxxx is hacked」とか「xxxx is compromised」とかで、発信人は自分。xxxxは自分のメールアドレス。
英語の内容は、
・fromを見れば分るように6か月以上前にお前のxxxxのパスワードは破った。
・そして自分の作ったトロイの木馬ウィルスをお前のPCに送り込み、お前の動きを長い間モニターしている。
・パスワードを変更しても私に通知が来るから無意味だ。
・お前のPCのデータや写真、ビデオ、お前の使っているネットアカウントは抜き取った。
・お前の動きはカメラを通じてモニターし記録ている。カメラの前で何を興奮してるんだ。
・ 48時間以内に500ドル払えばこれらの情報を捨ててやるのでビットコインの指定したウォレットに支払え。良い勉強したと思えば安いもんだ。
てな感じだ。
しかしfromは簡単に改ざんできるし、残念ながら私のPCにはカメラは付いていない。
結局ハッキングに成功したという証拠は何も示されていない。
そもそもビットコインを入手できたとして、どうやったら誰が支払ったか分かるのだろうか？ ・・・まあいいか、放置で。
そして2日後には同じ内容で566ドルに値上がりし期限が50時間に延長されたメールが届いた。
そしてさらに10日後には820ドルに値上がりし期限が48時間に戻ったメールが届いた。
「これはfantasyじゃないぞ」ってな脅し文句も付いてきた。
そしてその後も時々続いている。
おまけに「あなたのパスワードが侵害されました」というタイトルの日本語メールも来たがヘッダーのエンコーディング情報が間違っているのか内容は化けていて読めない（何でもござれのoutlookで受けたら表示するかもしれないが、私は使っていない）。
Received: fromの内容は全て異なる。
My nickname in darknet is yyyy の自己紹介名も全て異なっている。ビットコインの振込先も１つではない。
試しにfromをトレースするとアルメニア、パキスタン等だったが、これはbotだろう。
ビットコインの換金方法や送金方法も知らんし、まあ単なる脅しだろうから放っておけばいいんだけど、1年ほどバックアップを取っていないことを思い出したのでHDDを丸ごとバックアップした。
ぼちぼち終活も考える時期だし、いっそ丸ごと消してくれたら諦めがつくんだけど。
ちなみにこんな怪しいメールはしかるべき所に即通報してます。
ネットニュースにも流れていたね、この件。
すでに支払った人もいるみたい。
ちなみに、これまで来た件名は次の通り（新しいタイトルが来たら順次追加します）。日本語のメールはエンコーディングが誤っており本文が読めない。
・xxxx was hacked
・xxxx is compromised
・あなたのパスワードが侵害されました (xxxx)
・xxxx is compromised. Password must be changed
・Change your password immediately. Your account has been hacked.
・Hacking Alert! You account was hacked・Security Scam Warning.
・xxxx - このアカウントはハッキングされています
・xxxx - ハッキングされています！ すぐにパスワードを変更してください！
・Third party accessed to xxxx
・xxxx 被黑了！ 立即更改密码！・・・・中国語のこれもそうかな？
・Your account is being used by another person!
・Your account was under attack! Change your access data!
・High danger. Your account was attacked.
・Frauders known your old passwords. Access data must be changed.
・Caution! Attack hackers to your account!
・The decision to suspend your account. Waiting for payment.
・Be sure to read this message! Your personal data is threatened!
・Security Alert. Your accounts was hacked by criminal group.
タイトルは「xxxx is hacked」とか「xxxx is compromised」とかで、発信人は自分。xxxxは自分のメールアドレス。
英語の内容は、
・fromを見れば分るように6か月以上前にお前のxxxxのパスワードは破った。
・そして自分の作ったトロイの木馬ウィルスをお前のPCに送り込み、お前の動きを長い間モニターしている。
・パスワードを変更しても私に通知が来るから無意味だ。
・お前のPCのデータや写真、ビデオ、お前の使っているネットアカウントは抜き取った。
・お前の動きはカメラを通じてモニターし記録ている。カメラの前で何を興奮してるんだ。
・ 48時間以内に500ドル払えばこれらの情報を捨ててやるのでビットコインの指定したウォレットに支払え。良い勉強したと思えば安いもんだ。
てな感じだ。
しかしfromは簡単に改ざんできるし、残念ながら私のPCにはカメラは付いていない。
結局ハッキングに成功したという証拠は何も示されていない。
そもそもビットコインを入手できたとして、どうやったら誰が支払ったか分かるのだろうか？ ・・・まあいいか、放置で。
そして2日後には同じ内容で566ドルに値上がりし期限が50時間に延長されたメールが届いた。
そしてさらに10日後には820ドルに値上がりし期限が48時間に戻ったメールが届いた。
「これはfantasyじゃないぞ」ってな脅し文句も付いてきた。
そしてその後も時々続いている。
おまけに「あなたのパスワードが侵害されました」というタイトルの日本語メールも来たがヘッダーのエンコーディング情報が間違っているのか内容は化けていて読めない（何でもござれのoutlookで受けたら表示するかもしれないが、私は使っていない）。
Received: fromの内容は全て異なる。
My nickname in darknet is yyyy の自己紹介名も全て異なっている。ビットコインの振込先も１つではない。
試しにfromをトレースするとアルメニア、パキスタン等だったが、これはbotだろう。
ビットコインの換金方法や送金方法も知らんし、まあ単なる脅しだろうから放っておけばいいんだけど、1年ほどバックアップを取っていないことを思い出したのでHDDを丸ごとバックアップした。
ぼちぼち終活も考える時期だし、いっそ丸ごと消してくれたら諦めがつくんだけど。
ちなみにこんな怪しいメールはしかるべき所に即通報してます。
ネットニュースにも流れていたね、この件。
すでに支払った人もいるみたい。
ちなみに、これまで来た件名は次の通り（新しいタイトルが来たら順次追加します）。日本語のメールはエンコーディングが誤っており本文が読めない。
・xxxx was hacked
・xxxx is compromised
・あなたのパスワードが侵害されました (xxxx)
・xxxx is compromised. Password must be changed
・Change your password immediately. Your account has been hacked.
・Hacking Alert! You account was hacked・Security Scam Warning.
・xxxx - このアカウントはハッキングされています
・xxxx - ハッキングされています！ すぐにパスワードを変更してください！
・Third party accessed to xxxx
・xxxx 被黑了！ 立即更改密码！・・・・中国語のこれもそうかな？
・Your account is being used by another person!
・Your account was under attack! Change your access data!
・High danger. Your account was attacked.
・Frauders known your old passwords. Access data must be changed.
・Caution! Attack hackers to your account!
・The decision to suspend your account. Waiting for payment.
・Be sure to read this message! Your personal data is threatened!
・Security Alert. Your accounts was hacked by criminal group.
2018年9月15日土曜日
燃費 99.9Km/L
最近の車は燃費が表示される。次の写真は借りたプリウスの燃費。流石のハイブリッドでもここまで行くのか？
実はこれは車庫から出すときの燃費。最初は0.0Km/Lであるが、走り始めはバッテリーだけで動くからオーバーフローしてこうなるんだろう。エンジンがかかると急激に1桁まで低下し、その後徐々に20Km/L以上まで上昇する。
一般にキーをONにしたときの燃費は計算上0÷0で不定の筈であり、これを0と表示したり標準的な値を表示したりと、車ごとに色々のようである。
一般にキーをONにしたときの燃費は計算上0÷0で不定の筈であり、これを0と表示したり標準的な値を表示したりと、車ごとに色々のようである。
2018年8月26日日曜日
今年もハムフェア 2018
今年も暑い中で行ってきました。
最近外国のハムクラブの展示が年々増えているように感じます。今回特に買いたくなるものも無かったけど、SDR的なものが円熟期に入ったような気がしました。なぜかCW関係が元気です。
昨年留守番が一人だけで閑散としていたPRUGのブースには今年は数名の方が詰めてあって、AX.25を拡張したFX.25のプロトタイプTNCを作っているみたいなポスターと実物らしき物が展示してありました。X.25由来のAX.25は元々品質の良い回線を相手にしているので１ビットでもエラーがあるとフレームを捨ててしまいます。そこで回線品質が悪いと途端にリトライが始まり、特に回線遅延が大きい場合に疎通が極端に悪くなるんですが、FX.25では衛星通信で使うような Forward Error Correction（前方誤り訂正）をやるのでそれが改善されるようです。またAX.25を内包していて、AX.25でも通信できます。今後の成り行きをフォローしたいものです。
CQ出版のブースで再免許の書類を買ってきましたが、電波法のスプリアスの規定が変更になりH34年でJARLの補償が無効になるような記載が・・・。
昨年留守番が一人だけで閑散としていたPRUGのブースには今年は数名の方が詰めてあって、AX.25を拡張したFX.25のプロトタイプTNCを作っているみたいなポスターと実物らしき物が展示してありました。X.25由来のAX.25は元々品質の良い回線を相手にしているので１ビットでもエラーがあるとフレームを捨ててしまいます。そこで回線品質が悪いと途端にリトライが始まり、特に回線遅延が大きい場合に疎通が極端に悪くなるんですが、FX.25では衛星通信で使うような Forward Error Correction（前方誤り訂正）をやるのでそれが改善されるようです。またAX.25を内包していて、AX.25でも通信できます。今後の成り行きをフォローしたいものです。
CQ出版のブースで再免許の書類を買ってきましたが、電波法のスプリアスの規定が変更になりH34年でJARLの補償が無効になるような記載が・・・。
2018年8月23日木曜日
やってくれますMicrosoft
仕事で60台ほどのPCを管理しているが、Windows10 1803 の8月定期更新（KB4343909）を適用してから動きが変わった。
多くのPCを管理するため1台のPCでバッチファイルを組み、その中でPsExec.exeを使って他のPCで遠隔コマンドを実行させているが、やってみると7月までうまく行っていたのに、今月はエラーメッセージのオンパレードだ。
Make sure that the default admin$ share is enabled on xxxxx.
xxxxx:
Could't access xxxxx:
ネットワークパスが見つかりません。
ときた。default admin$ shareって何だ？
ネットで検索するとnet share コマンドで確認できるらしいが、実物を見ても問題は無さそう(というかビールスの感染ルートなので用が無ければ塞ぐべきか)。そのほかUACだ何だと出るが、書いてあることを試しても効果が無い。そこでネットワークパスに着目した。要するに「ネット上でPCが見つからない」って事だろう。すでに動いていたカラクリなのでユーザとしては名前以外は手の出しようがない。Windowsのコンピュータ名は大文字と小文字を区別しない仕様だった筈なので、これまでこの違いを放置していた。
試しにコンピュータ名を正確に打ち直してみると状況が変わった。エラーにはなるがPCにはアクセスできている。要するにPCの名前の大文字と小文字を（勝手に）区別するようになってPCの名前が解決できなくなったようだ。そこで大文字小文字を合わせてアクセスできるようにした。
しかし、今度はログインを拒否される。 PsExecのパラメータで指定したユーザ名/パスワードが受け入れてもらえないようだ。試しに、ローカルアカウントであることを表すためにユーザ名の頭に付けている「.\」を外してみた。すると何事も無かったように動くようになった。
これらを踏まえると、8月15日の更新でコンピュータ名やユーザ名に関する扱いが変わってるようだ。これが意図されたものかバグかは分からないが影響は相当なものだと考えられる。クラッカー対策かもしれないが、我々みたいに他に困っている人は大勢いると思うのだが。
まあ PsExecなんて普通の人は使わないか。
多くのPCを管理するため1台のPCでバッチファイルを組み、その中でPsExec.exeを使って他のPCで遠隔コマンドを実行させているが、やってみると7月までうまく行っていたのに、今月はエラーメッセージのオンパレードだ。
Make sure that the default admin$ share is enabled on xxxxx.
xxxxx:
Could't access xxxxx:
ネットワークパスが見つかりません。
ときた。default admin$ shareって何だ？
ネットで検索するとnet share コマンドで確認できるらしいが、実物を見ても問題は無さそう(というかビールスの感染ルートなので用が無ければ塞ぐべきか)。そのほかUACだ何だと出るが、書いてあることを試しても効果が無い。そこでネットワークパスに着目した。要するに「ネット上でPCが見つからない」って事だろう。すでに動いていたカラクリなのでユーザとしては名前以外は手の出しようがない。Windowsのコンピュータ名は大文字と小文字を区別しない仕様だった筈なので、これまでこの違いを放置していた。
試しにコンピュータ名を正確に打ち直してみると状況が変わった。エラーにはなるがPCにはアクセスできている。要するにPCの名前の大文字と小文字を（勝手に）区別するようになってPCの名前が解決できなくなったようだ。そこで大文字小文字を合わせてアクセスできるようにした。
しかし、今度はログインを拒否される。 PsExecのパラメータで指定したユーザ名/パスワードが受け入れてもらえないようだ。試しに、ローカルアカウントであることを表すためにユーザ名の頭に付けている「.\」を外してみた。すると何事も無かったように動くようになった。
これらを踏まえると、8月15日の更新でコンピュータ名やユーザ名に関する扱いが変わってるようだ。これが意図されたものかバグかは分からないが影響は相当なものだと考えられる。クラッカー対策かもしれないが、我々みたいに他に困っている人は大勢いると思うのだが。
まあ PsExecなんて普通の人は使わないか。
2018年8月3日金曜日
LT-R6のカラクリ（その１）
最後にLT-R6を公開してから数年が過ぎた。その間にいくつかのバグレポートをいただき、修正も済んでいるがリリースする気になれないまま月日が経った。時間が経つと、それに見合った機能追加をしないと格好がつかない、と考えたまま今日に至っている。アイデアはあるが気力が続かない。
そんなこともあり、とりあえずここでLT-R6についてこれまで書かなかった中身を少し公開しよう。CI-Vは1本の線を共用して双方向の通信を行うため、CI-V上を流れる個々のデータからはそれが何かは判別できない。通信の内容を解析するには先ずCI-Vの調歩同期信号を受信・UARTで再生し（ここまではクローニングケーブルの仕事）、その後バイト単位で受信したデータからフレーム（以下、CI-Vの基本フォーマットのプリアンブル (0xFE)からEOM (0xFD)までをこう表現する）を再構成し、その中身を解析することで誰が何の目的で送信したフレームかを判別する。このときIC-R6とLT-R6の双方がランダムにデータを送信することで起きる信号の衝突や、衝突を検出した場合に送出される連続したJammer(0xFC)、及びその後のフレームの再送に対応した処理を行う必要がある。実際にCI-VをモニターしているとJammerはよく見られる。
フレームの再構成にはステートマシンを使う。LT-R6には3つのステートマシンを内蔵している。通信用、メモリーデータ受信用、及びCI-Vプロトコル解析用だ。通信用は通常のLT-R6の動作に使う。この場合正常にフレームを受信した時だけ結果を上位ソフトに上げればよいが、ただし自分が送信したデータをモニターし、もし潰れていた時は衝突が起きているのでJammerを送出してアボート（中断）処理を行い双方の状態を整合させるようにしている。メモリーデータ受信用も同様だが制御に使うコードが違う。通信用、メモリーデータ受信用は送信部との連携がある分だけややこしい。
一方プロトコル解析用はCI-Vの全てのデータを抜けなくキャプチャーするのみで単純である。解析用ステートマシンの状態遷移表を抜き出すと次のようになっている（作者独自の書式）。
* STATE MACHINE
* State OUTFR SYNC INFR ABT
* /Input(event)
* SYN(FE) +/SYNC +/SYNC x]+/SYNC x]+/SYNC
* EOM(FD) +/OUTFR x]+/OUTFR +]]/OUTFR x]+/OUTFR
* JAM(FC) x]+/ABT x]+/ABT x]+/ABT +/ABT
* ELSE +/OUTFR +/INFR +/INFR x]+/OUTFR
* TM-OUT x]/OUTFR x]/OUTFR x]/OUTFR x]/OUTFR
*
* SYMBOLS:
* -: abandon data
* +: accept data
* ]]: complete with success
* x]: complete with error
ステートマシンは状態を持ち、通信に伴って発生するイベントに対しアクション/次の状態を記述する。 OUTFR,SYNC,INFR,ABTが状態であり、SYN,EOM,JAM,ELSE,TM-OUTがイベントである。例えばフレーム受信中(INFR)にフレーム開始(SYN)を受信すると、受信は異常終了し（x]）データ(SYN)は取り込み(+)、次の状態をプリアンブル部(SYNC)とする。
TM-OUTはフレーム受信中の一定時間内にフレームが完結しない場合の処理である。
ステートマシンは通信ライブラリから渡されるCI-V受信データを処理する。通信ライブラリはCI-Vデータを受信するとそれを受信バッファに積み、次にデータが入ったというイベントを発生する。このイベントを受けてスレッド（イベントディスパッチングスレッド）が実行され、その中でステートマシンを実行することになる（少し専門的ですがご勘弁）。スレッドを実行中に通信ライブラリは次のデータを受信する可能性があり、1バイト受信する度にイベントが発生する訳ではない事を含めてロジックを組む必要がる。リアルタイム処理ではここら辺りがややこしくていまだに理解不十分な点があるかもしれないが結果オーライで実装している。
リアルタイム処理のデバッグは処理を止めて解析できないので厄介である。とくに以前ci-vの受信に使っていたrxtxライブラリーには受信したデータがライブラリーの中に詰まるような現象を起こす問題があり、それを発見し対処するのには長期間を要した。現在のjSSCライブラリーに変えてからはこれまでそのような問題はない。
続く
そんなこともあり、とりあえずここでLT-R6についてこれまで書かなかった中身を少し公開しよう。CI-Vは1本の線を共用して双方向の通信を行うため、CI-V上を流れる個々のデータからはそれが何かは判別できない。通信の内容を解析するには先ずCI-Vの調歩同期信号を受信・UARTで再生し（ここまではクローニングケーブルの仕事）、その後バイト単位で受信したデータからフレーム（以下、CI-Vの基本フォーマットのプリアンブル (0xFE)からEOM (0xFD)までをこう表現する）を再構成し、その中身を解析することで誰が何の目的で送信したフレームかを判別する。このときIC-R6とLT-R6の双方がランダムにデータを送信することで起きる信号の衝突や、衝突を検出した場合に送出される連続したJammer(0xFC)、及びその後のフレームの再送に対応した処理を行う必要がある。実際にCI-VをモニターしているとJammerはよく見られる。
フレームの再構成にはステートマシンを使う。LT-R6には3つのステートマシンを内蔵している。通信用、メモリーデータ受信用、及びCI-Vプロトコル解析用だ。通信用は通常のLT-R6の動作に使う。この場合正常にフレームを受信した時だけ結果を上位ソフトに上げればよいが、ただし自分が送信したデータをモニターし、もし潰れていた時は衝突が起きているのでJammerを送出してアボート（中断）処理を行い双方の状態を整合させるようにしている。メモリーデータ受信用も同様だが制御に使うコードが違う。通信用、メモリーデータ受信用は送信部との連携がある分だけややこしい。
一方プロトコル解析用はCI-Vの全てのデータを抜けなくキャプチャーするのみで単純である。解析用ステートマシンの状態遷移表を抜き出すと次のようになっている（作者独自の書式）。
* STATE MACHINE
* State OUTFR SYNC INFR ABT
* /Input(event)
* SYN(FE) +/SYNC +/SYNC x]+/SYNC x]+/SYNC
* EOM(FD) +/OUTFR x]+/OUTFR +]]/OUTFR x]+/OUTFR
* JAM(FC) x]+/ABT x]+/ABT x]+/ABT +/ABT
* ELSE +/OUTFR +/INFR +/INFR x]+/OUTFR
* TM-OUT x]/OUTFR x]/OUTFR x]/OUTFR x]/OUTFR
*
* SYMBOLS:
* -: abandon data
* +: accept data
* ]]: complete with success
* x]: complete with error
ステートマシンは状態を持ち、通信に伴って発生するイベントに対しアクション/次の状態を記述する。 OUTFR,SYNC,INFR,ABTが状態であり、SYN,EOM,JAM,ELSE,TM-OUTがイベントである。例えばフレーム受信中(INFR)にフレーム開始(SYN)を受信すると、受信は異常終了し（x]）データ(SYN)は取り込み(+)、次の状態をプリアンブル部(SYNC)とする。
TM-OUTはフレーム受信中の一定時間内にフレームが完結しない場合の処理である。
ステートマシンは通信ライブラリから渡されるCI-V受信データを処理する。通信ライブラリはCI-Vデータを受信するとそれを受信バッファに積み、次にデータが入ったというイベントを発生する。このイベントを受けてスレッド（イベントディスパッチングスレッド）が実行され、その中でステートマシンを実行することになる（少し専門的ですがご勘弁）。スレッドを実行中に通信ライブラリは次のデータを受信する可能性があり、1バイト受信する度にイベントが発生する訳ではない事を含めてロジックを組む必要がる。リアルタイム処理ではここら辺りがややこしくていまだに理解不十分な点があるかもしれないが結果オーライで実装している。
リアルタイム処理のデバッグは処理を止めて解析できないので厄介である。とくに以前ci-vの受信に使っていたrxtxライブラリーには受信したデータがライブラリーの中に詰まるような現象を起こす問題があり、それを発見し対処するのには長期間を要した。現在のjSSCライブラリーに変えてからはこれまでそのような問題はない。
続く
登録:
投稿 (Atom)