[llcp]nfcpyを推測してみるも、謎が増えるばかり

なぜnfcpyのLLCPは、CONNECT PDU受信時のDSAPを1(SDP)限定にしているのか。
ちょっと推測してみよう。

---

【その前に解説】
最近のhiro99maは訳のわからないことばかり書いてあるわ、と思われそうなので、今さらだが簡単に用語の説明をします。
まあ、訳がわからないのは最近に限ったことではないですがね。。

 

LLCP
Logical Link Control Protocolの略。
NFC Forumにて、NFC端末同士の通信に使うプロトコルとして指定されている。

 

PDU
Protocol Data Unitの略。
LLCPで使用するデータの単位。
通信するのでお互いにデータを送受信するのだが、1回の送信で1つのPDUを送信する。
PDUにはタイプがあって、タイプごとに載っているデータも異なる。

 

CONNECT
PDUタイプの１つ。
接続要求をするときに送信する。

 

SAP
Service Access Pointの略。
PDUのパラメータになっている。
サービスってのはあちこちで使われている言葉だが、LLCPでは「やりたいこと」みたいな意味のようだ。
原文では「The capabilities and features provided to the adjacent upper layer」。
たとえば「SNEP」というさらに上位のプロトコルがあるのだが、それを使った通信をしたいときにはPDUのSAPにSNEPの値(文字列とかではなく、数値なのだ)を指定する。
NFC Forumでの値は、こちら。

 

DSAP
Destination SAPの略。
自分をSource、相手をDestinationと呼んでいて、それぞれSSAP、DSAPという名前になる。
PDUにはSSAPとDSAPをパラメータとして与えるようになっている。

---

時代背景を見てみる。

nfcpyがLLCPを搭載して「NexusSと通信できた」と報告している。
このときは、Android 2.3と書いている。
Android 2.3に搭載しているのは、LLCP v1.0のはず。
なぜかというと、LLCP v1.1がリリースされたのは、2011年6月20日。この記事が2011年5月だから、少なくとも正式リリースはまだだ。

Android 2.3には、NDEF Pushというプロトコル[pdf]が搭載されている。
これは、LLCPの上位層で、SNEPよりも前にリリースされている(2011年2月22日)。

そう考えると、当時はLLCPで通信するものはNDEF Pushだけだったと考えられる。

 

このNDEF Pushだが、サーバの要件として「com.android.nppという名前でサービス検索できること」という項目がある。
サービスの検索は、Service Discovery Protocolというプロトコルがあり、これ自体が１つのサービスになっている。
つまり、SAPが割り当てられているということだ。

Service Discovery Protocol(SDP)のSAP値は、1。
だから、LLCP接続しに来る人はSAPが1のはず、という実装になってるんじゃないだろうか？

---

などと書いてみたが、nfcpyからAndroid Beamできるようなのだよ。

 

ありがたいことに、ここにnfcpyでSNEPしたときのログが載っていた。
相手は、Samsung Nexus (Android 4.0.3)らしい。
RemoteのService Listが「0000000000000001」になっている。
これだと、有効なSAPがデフォルトのしかない、ってことになるんだよなあ。

 

と思ってログを見直すと、nfcpyのLocal Service Listが「0000000000000011」だ。
あれ、SDPしかないじゃないの！
SNEPのビットが立ってないじゃないか！！
・・・でも、自作LLCPに送られてきた情報では、SNEPのビットが立ってる。
どういうことなのだ？

もしかして、SDPでSNEP検索できるのか？
でも、だからってDSAP==1のみってのはなぁ。。。