息詰まる展開！だったらいいのだが、行き詰まっている・・・。
いつものことながら、NFCのLLCPについてだ。
LLCPのLink Activationが終わると、通信を始めることができる。
Normal Operation、という状態だ。
そのとき、UDP/IPみたいなConnectionless Transport Modeか、TCP/IPみたいなConnection-oriented Transport Modeかによって、シーケンスが変わってくる。
私はSNEPしたいので、Connection-oriented。
最初に使うPDUは、「5.6.3 Connection Establishment」によるとCONNECTだ。
さて、ここで問題だ。
誰がCONNECT PDUを送信するのか？
LLCPの開始は、InitiatorがATR_REQを投げ、TargetがATR_RESを返す。
この段階でLink Activationが終わると思うので、ボールはInitiatorが持っている。
だから、CONNECTはInitiatorが投げるのだろう。
だろうと思っていたのだ。
しかしnstの実装を見てみると、CONNECTが来るとLinkを切断しようとしているのだ。
InitiatorからはSYMMを送ってくるので、それに対してnstがCONNECTを投げるようになっている。
なんだ、この自信ありげなCONNECT排除の実装は！
ここまで実装されていると、仕様として何か記載があるんじゃないかと思う。
思うのだけど・・・見つけられない。
この数時間、仕様書をにらみつけているが、さっぱりわからん。
暴れてしまいそうだ。
SYMMが来たとしても、自分でCONNECTする、という実装ならわかるのだが、相手から来たCONNECTを断るというのは、何か確信があってのことに違いない。
こういうのを誰かに質問したくてGoogle検索から削除したのだけど・・・出てこんなぁ。
以下、体験上の想像ですが。
返信削除Initiator云々はNFC-DEPの層の話で、LLCPはそれの上に乗るプロトコルですよね。
なので、Initiator-Targetの主従とLLCPの層の主従は同じじゃなくても良いのだと思います。
nstの実装では、おそらくInitiatorの主従とLLCPの主従が逆の例なんだと思います。
例えば、AndroidBeamでくっつけた時にどっちがInitiatorになるかはP2Pなんでどっちでもいいですが、データを実際に送るのにはクライアントとサーバという主従なモデルになります。
で、NFC-DEPの層までつながったあと、LLCPで「相手から」の場合に、SYMMで相手にバトンを渡すんでは。
SNEPで、レスポンス受信前にSYMMにより送り手と受け手を逆転させるのと同じSYMMかと思われます。
相手からきたCONを断るってのは、あくまでLLCPで俺からつなげて俺が出すみたいななんかがあるんですかね。
Android端末とお話すると、フツーにCONNECTに応答返ってきますよ。
LLCPのあたりって、「各APIの口は仕様が決まってるけど使い方やシーケンスについては全く書いてない」って感じで面倒ですよね・・・
こんな細かい記事に、コメントありがとうございます。
返信削除見てくださってる人がいるだけでうれしいものです。
>で、NFC-DEPの層までつながったあと、LLCPで「相手から」の場合に、SYMMで相手にバトンを渡すんでは。
はい、私もこれだろうと思っているのですが、根拠になる仕様が見つからないので迷っているところです。
実機がないので、仕様書から組み立てているのがつらいところです。
>Android端末とお話すると、フツーにCONNECTに応答返ってきますよ。
えぇ！ そうなんですか！！
てっきり、絶対にAndroid端末はCONNECTを返さないからこういう実装になってるのだろうと思ってました。
>LLCPのあたりって、「各APIの口は仕様が決まってるけど使い方やシーケンスについては全く書いてない」って感じで面倒ですよね・・・
はい・・・
よくわかってないので、何がどう連携して動くべきなのかが見えずにいるところです。
IEEEのLLCの仕様を読むともうちょっと理解が進むのでは、という気もしているのですが、読むかどうかでまた迷っています。。。
私のケースでは、こちらがInitiatorで、NFC-DEPつなぎ始めるのもLLCP語りかけるのもこちら側という形で、Androidに対してCONNECTかけてCCもらって、SNEPでURLなんかを渡せてますよー。。
返信削除想像ですが、見ているNSTのソース、「送る側」のソースなんでは？
まさに、その通りです。
返信削除こちらはTargetで、InitiatorからのATR_REQに対してATR_RESを返したあと、SYMMをもらってこちらからCONNECTするような流れになっていました。
最後はこちらからSNEP PUSHで送信する、という作りです。
ということは、Androidは両刀遣いで、まずはCONNECTを相手から要求させるような作りになっている、ということですかね。
CONNECTした側がCCをもらうので、送信したい人がCONNECTを投げるのは流れとしてはしっくりくるのですが、そこはLLCPの範囲外ということのような気がしてきました。
両刀といいますか、P2Pなんで基本どっちがどっちになるか分からないのでどっちも実装されてるのではないでしょーか。
返信削除先の例のAndroidBeamなんかだと端末同士くっつけただけでBeam準備動作に入りますので、この時どちらがInitiatorになるかはタイミング次第だったりするような気がします。
それはそれとして、Android相手に「こちらがInitiator」でNFC-DEPの層でつなげてやると、とくにSYMMとか来ずにCONNECTできたような・・・
>先の例のAndroidBeamなんかだと端末同士くっつけただけでBeam準備動作に入りますので、この時どちらがInitiatorになるかはタイミング次第だったりするような気がします。
返信削除なるほど。
ということは、「俺は送るものがないから、あんたが何かしたいんでしょう」ということでSYMMを送ってくるんですかね。
>それはそれとして、Android相手に「こちらがInitiator」でNFC-DEPの層でつなげてやると、とくにSYMMとか来ずにCONNECTできたような・・・
今回見ているnstなのですが、かなり実装としてはかなり省かれていて、LLCPはTarget専門になっているようでした。
SNEPはAndroid相手を前提に実装しているのでは？、という推測をしています。
なので、「Android端末はCONNECTを投げずにSYMMを送信するという仕様なのでは…」と疑ったのでした。
たしかに、普通はAndroid端末同士をくっつけたときを想定しているので、タイミング次第でどっちかがどっちかになりますね。
それを利用して、「自分がTargetで、送信するデータを持っている端末」という動きをすると、nstの想定するシーケンスになるような気がしてきました。
(自分がInitiatorになるよりも、待ち受けた方が確実、という考え方ですかね。)
なんとなく整理できてきたような気がします。
ええと、nstはまさに「tag」なんで、NFCケータイなどから「読まれる」ことを前提としているんではないですかね。
返信削除なので、実装省略と言うよりは、読まれるTargetのタグモードとして必要な実装をしてあるという感じでは。
NFC関連ってどうなんでしょうね、シーケンスが提示してないから、どう使われるかって「早く実装した者勝ちで他の人はそれに合わせる」なんですかねw
調べてもなかなか出てこないことも多いんで、よろしければぜひ情報交換を。
>NFCケータイなどから「読まれる」ことを前提としているんではないですかね。
返信削除確かに「tag」でしたね…
実装を簡略化してある、という話だけは聞いたのですが、どこまでが必要で、どこまでが簡略なのかが今ひとつわかってないです。
>シーケンスが提示してないから、どう使われるかって「早く実装した者勝ちで他の人はそれに合わせる」なんですかねw
うぅ、それだと実機を持っていない人にはつらい・・・。
ようやくシーケンスが見つかったのがnstだったので、それを参考にしているのでした。
http://code.google.com/p/nfc-smart-tag/wiki/NfcProtocols
>調べてもなかなか出てこないことも多いんで、よろしければぜひ情報交換を。
はい、私もわかっていない部分がかなりあるので、ぜひお願いします。