[falp]4. OBEX connect

見たところ、FALPは以下の順で行っていると推測している。
推測に沿って見ていく。
1. R/Wの準備
2. 準備1
3. 準備2(OBEX準備?)
4. OBEX connect
5. OBEX put
6. OBEX disconnect
7. 終了

---

4. OBEX connect
こっから先は、実はFALPとはあまり関係がない。
FALP転送コマンドでOBEXパケットをやりとりするところだ。
FeliCaコマンド0xbcで送る。
このコマンドはいつものと少し違う。
普段、コマンドを投げるとレスポンスとして+1した値が返ってくる。
しかしこの0xbcは、レスポンスがない。
あるのかもしれないが、少なくとも返ってきているのは確認できなかった。
どうするかというと、相手も0xbcで返してくる。
足を止めてのインファイトだ(意味不明)。

---

今回のOBEX は、

1. CONNECT(0x80)
2. PUT(0x82)
3. DISCONNECT(0x81)

だけである。
後ろに書いた値は、コマンド値だ。
CONNECTがFALPとして渡す最初のデータだからか、シーケンス番号が0x0000だった。
0xbcはレスポンスがないと書いたが、R/Wのコマンドに対するレスポンスはある。
これが・・・いつもの戻り値と違うのだ。
R/Wに直接データを渡す系統のコマンドは、だいたい「結果」が1byteある。
0x00なら成功で、それ以外はエラーというのが一般的だ。
しかしここでは、普通に0x01が返ってくる場合が多い。
うまくいっていないわけではない。
そういう応答みたいなのだ。
もちろん、0x00の場合もある。
そのときは、0xbcに続けてデータがやってくる。
なので、私はこう考えた。

• 0x01で返るときは、相手から送るデータがない場合
• 0x00で返るときは、相手からのデータがある場合

---

ではこちらはどう動いているかというと、これがまたよくわからない。
例のコマンド。
あれをデータ長無しで送っているのだ。
これが相手に渡ると、さっきの0x01になるのだろうか？
そして困るのが、パラメータが毎回異なること。
同じ値であれば、わからないなりに同じ値を使うのだが・・・。
そこで私が得た結論は、こうだ。

• 例のコマンドの第１、第２パラメータは、やはりタイムアウトで正しい
• タイムアウト値はランダム

そうでないと、説明が付かない。
RFConfigurationでタイムアウト値を設定するところがあるのだが、この範囲内でやっているのかもしれないし、FALPのHELLOでパラメータがたくさんあったから、その範囲でやっているのかもしれない。
そこのところは、よくわからん。
わからんが、ランダム値だろう。
今回の実装では、めんどくさいので固定値にした。

---

ちなみにOBEX CONNECTは、0x00が正しい。
ただOBEXは複数回パケットをやりとりすることを想定していて、最後に送るコマンド値は最上位ビットを立てるようになっている。
だから、0x80になるのだ。
CONNECTを受け付けると、相手から0xa0が返ってくる。
これも、0x20の最上位ビットがついたものかもしれん。
CONNECTを行うと、相手のバッファサイズなどがわかるので、小さい方に合わせてやりとりをするのかな。
いや、FALPはFALPコマンドの中で同じようなことを最初にやっているはずだ。
ここのところは、FALPの仕様書レベルものがないとわからんだろう。