[snep]SNEPはclient/server構造

いただいたコメントを見つつ考えていた。

Android端末に対してInitiatorとして働きかけた場合の動作。Targetとして動くときの動作。
どちらについても、なぜかAndroid端末は同じような動きをしているように見える。

ということは、その上位層であるSNEPが関係しているのではなかろうか。

---

SNEPは、client/server構造である。
つまり、SNEPサーバがSNEPクライアントを待ち受け、要求が来たらそれに応えるという形と考えてよいだろう。

私はAndroidのソースを読んで、AndroidがInitiatorとなって周りに問いかけ、それに応答したTargetがSNEP接続して送信してくる、という構造なのだろうと思っていた。
しかし、周りがInitiatorとなってAndroid端末に話しかけるというパターンも可能であることをコメントで知った。

 

ならば、Androidは両刀遣いということか？
いや、変な意味ではなく、InitiatorとしてもTargetとしても動作するけど、何かの決めごとによってSNEP serverかSNEP clientになるということになっているのでは、という意味だ。
SNEP serverになる方は、CONNECT権を相手に渡したいのでSYMMする、というストーリーだ。

---

さらにコメントをいただいて考えていたのだが、考慮が足りていないところがあった。

 

(コメントより)
先の例のAndroidBeamなんかだと端末同士くっつけただけでBeam準備動作に入りますので、この時どちらがInitiatorになるかはタイミング次第だったりするような気がします。

 

私はずっと、SNEPサーバがInitiatorで、SNEPクライアントがTarget、という考え方をしていた。
福岡NFC勉強会で、オシロを使った搬送波の動きを見て、何となくその仮定が違っているのではないかという気がしていた。

 

(コメントより)
両刀といいますか、P2Pなんで基本どっちがどっちになるか分からないのでどっちも実装されてるのではないでしょーか。

なんとなくわかっていたつもりだったのだが、この「どっちがどっちになるかわからない」はInitiator/Targetの関係で、SNEP client/serverの関係はまた別ということまでは考えが及んでいなかった。

つまり、こう言い換えることができるのではないか。

• データを送信したい側がInitiatorになるとは全然限らない。タイミング次第。
• データを送信したい側はSNEP clientで、受信する側はSNEP server。
• Androidでは動的にSNEP client/serverが切り替わり、「現在は送りたいデータがない」端末がSNEP serverになり、「現在送りたいデータがある」端末がSNEP clientになる。

こう考えると、nstの動きも理解できる。
nstは「常にTarget」で「常にSNEP client」の動作になる。
よって、相手は「常にInitiator」で「常にSNEP server」の動作になる。

Targetかつclientのnstに対して、Android端末は必ずATR_REQを投げることになる。
ATR_RESを返すnst。
それを受け取ったAndroid端末。しかし送るデータがないことを理解しているので、SYMMで接続権を相手に渡す。
SYMMをもらったnstは、喜々としてCONNECTを送信する、というストーリーだ。

---

しかし、まだ疑問は残る。

CONNECTで接続を確立したあとでSYMMを投げてもいいんじゃないのか、という点だ。
これについての規定があるなら、LLCPではなくてSNEPだろうな、と思う。