Serfの障害検知とメンバシップ管理について
はじめに
KLabさんの協力会社として一緒にお仕事をさせて頂いておりますクラスターコンピューティングと申します。今回Serfという面白そうなツールがあるので試してみました。システムの高可用性化を目的にクラスタを構成することはよく行われていると思います。可用性を維持するために大切なことはクラスタに属するサーバの状態を常に把握しておくことです。そしてサーバの状態に変化が生じた場合ーたとえばサーバが不意に停止した場合ーそれに応じて適切な動作ができるようにする必要があります。システムのサービスはこの土台となるサーバ管理の仕組みの上に構築されます。
Serfはこのクラスタの土台となるサーバの管理の部分をサポートしてくれるツールです。Serfはゴシッププロトコルを利用したP2P型のクラスタを構成します。これによりシンプルな作りでかつ信頼性やスケーラビリティに優れ、そしてネットワーク的な効率も良い管理システムを提供しています。
Serfの基本機能
本家ホームページ
SerfはHashcorpで開発されているクラスタの管理ツールです。
イントロダクションのページにも書かれていますが、Serfの基本機能は以下の3つになります。
- メンバシップ管理
- メンバの障害検知
- メンバへのイベント伝達
Serf はいわゆるP2P型のクラスタを構成します。クラスタを構成する全てのサーバ上でSerfエージェントが実行されています。クラスタを管理する中央サーバ的なものは存在せす、それぞれの Serfエージェントに役割や機能は同じです。Serfでは各エージェントが相互に通信することによって最新のクラスタの状態を把握することによりクラスタ構成しています。すべてのエージェントが保持しているクラスタについての情報は常に最新で同一のものになっています。
図1
Serfクラスタにはいわゆる中心サーバは存在せず、各エージェントが相互に通信することによってクラスタの状態を把握している。
Serfでのメンバシップ管理
Serfエージェントが実行されクラスタに所属しているサーバをメンバと呼びます。Serfにおけるメンバシップ管理は次の完全性に基いています。- メンバシップ管理における完全性：各メンバが他の全てのメンバの状態を常に把握している。
Serfではこの完全性を満たすため次のようなアプローチをとっています。
クラスタの状態に変化が発生したとき、少なくとも1つの正常なノードがそれを検知し、全体にそれを伝達(ブロードキャスト)する。
有限時間内それを検知し、それを有限時間内に全体に伝たえる。
例えば、自身の状態に変化が生じたときは自分でそれを全体に伝えるアクションを実行する必要があります。また、新たなメンバがクラスタに参加する際には、新規メンバはすでに参加しているいずれか1つのメンバを知っていればクラスタに参加できます。複数のメンバをもつクラスタのいずれか1つのメンバが別のクラスタに参加した場合、残りのメンバもそのクラスタに参加し全体でに1つのクラスタになります。
Serfのメンバシップ管理でやり取りされる情報は、メンバのホスト名、IPアドレス、障害ステータス(死活)、タグなどの情報です。
完全性を満たすためには確実に状態の変化を検知する仕組みおよびクラスタ全体にすみやかに情報を伝達する仕組みが必要になります。Serfではゴシッププロトコル的な手法を利用することによって、ネットワークの負荷を抑えつつこれらの仕組みを構築しています。
メンバの障害ステータス
メンバのステータスはserf membersというコマンドで取得することができます。どのメンバ上で実行しても同じ結果が得られます。server1 # serf membersserver1 192.168.0.101:7946 alive
server2 192.168.0.102:7946 alive
server3 192.168.0.103:7946 alive メンバの障害ステータスは正常(alive)、正常終了(left)、障害(failed)の3つの状態で表されます。
aliveは正常に他のメンバからそのメンバにアクセスできる状態です。
leftはSerfエージェントがserf leaveコマンドやCtrl-Cなどによって正常に終了したことを示しています。
Serfエージェントは正常に終了する際に自身の終了のクラスタ全体に通知します。
受け取った各エージェントはそのメンバのステータスをleftに変更して障害検知の対象から外します。
failed はそのメンバにアクセスができず障害と判断されていることを示しています。この場合はそのメンバに対する死活確認は継続し、復旧が確認された場合は自動的 にクラスタのメンバの復帰します。また、failedの状態で決められた期間(デフォルトでは24時間)が経過すると障害検知対象から外されるようにもなっています。
メンバのタグ
Serfではそのメンバ同士でタグを利用した簡単な情報の共有も可能です。タグとは foo=barで表されるようないわゆるキーバリューのことです。serf tagsコマンドを利用してそれぞれのメンバ上で設定します。各メンバに設定されたタグはserf membersコマンドで確認できます。タグのセット
server1 # serf tags -set foo=bar
Successfully updated agent tags
タグの確認
server2 # serf members
server1 192.168.0.101:7946 alive foo=bar
server2 192.168.0.102:7946 alive
server3 192.168.0.102:7946 alive
タグの消去
server1# serg tags —delete foo
タグもステータスと同様に全てのメンバで常に最新のタグ情報が共有されます。
Serfの障害検知とメッセージ伝達
メンバシップ管理での完全性を満たすためには、障害検知やメッセージのブロードキャストのためかかるネットワークの負荷が問題になります。そのための工夫としてSerfではゴシッププロトコル的な障害検知手法およびメッセージ伝達方法を利用しています。Serfの障害検知
図2
SWIMでの障害検知のイメージ複数の経路からメンバの死活を確認することにより確実性を高めている。
Serfのゴシッププロトコルについてのページ
SerfではSWIMという手法を利用して障害検知をしています。SWIMとは相互監視によるP2P型の障害検知方法で、次のような特徴があります。
- あるメンバの障害を残りの全ての正常なメンバが確実に検知できる。
- メンバの障害を信頼性の低いネットワークであっても誤検知しない。
- メンバの障害を速やかに有限の時間内で検知できる。
- メンバの障害検知のためのネットワーク負荷をクラスタの規模に応じて常に一定量にできる。
- 各メンバはお互いに常に短い周期で他のメンバの障害監視を行っている。ここではあるメンバ(D)について考える。
- メンバ(D)は自身の持っているメンバのリストからランダムに対象メンバ(T)を選択し障害を確認する。
- 対象メンバ(T)にアクセス(PING)を実行する。応答(ACK)がなかった場合すぐに障害と判断せずに、他のK個メンバ(S1...SK)に対象メンバ(T)への代替アクセスを要請(PING-REQ)する(図2ではK=3)。要請をするメンバも自身の持っているメンバのリストのなかからランダムに選択する。
- PING-REGを受け取ったメンバは代わりに対象メンバ(T)にアクセス(PING)して、その応答(ACK)があれば(D)に応答(ACK)を返す。
- (D)はタイムアウトまでにPINGあるいはPING-REQのACKが得られれば対象メンバ(B)は正常(Alive)と判断する。タイムアウトまでにACKが得られなかった場合、障害(Failed)と判断する。 障害と判断された場合、判断したメンバが全体にその旨を通知する。通知を受け取った各々のメンバは自身のもっている(T)のステータス情報を更新する。
メッセージ伝達
図3
各メンバ間では常時障害検知のためのパケットがランダムに行き来している。
障害検知のためのパケットにメッセージを載せることによりランダムな経路で全体にメッセージが伝達される。
SWIM では障害の検知と検知した障害の全体への通知を分けて考えています。初期のSWIMでは全体への通知はマルチキャストを利用していたようですが、確実性とネットワーク負荷の点で問題があったのでやめにしたようです。改良されたSWIMでは障害通知のパケットを障害検知のためのパケット(PING/ACK /PING-REQ)に載せて(Piggyback)伝達するようしています。
障害検知のパケットは常時それぞれのメンバからランダムな相手に対して送信されています。このパケットに便乗して通知のパケットを送信します。送られた先でさらに別の障害検知のパケットに便乗して再送信します。 このようにして、メンバからメンバにランダムに送信されていき、やがて全体に浸透します。これがいわゆるゴシッププロトコル的な方法になっています。
Serf ではこの便乗する仕組みを障害検知の結果の通知以外にも、イベントなどのメッセージの伝達する場合にも利用しています。ただ、障害検知のパケットの送信間隔がやや長く(1秒程度)これだけではメッセージの伝達速度的に問題があるので、メッセージを伝達するだけの専用のパケットを同様の方法でより短い間隔 (200ミリ秒)で送信しているようです。
障害検知のパケットがUDPなのでメッセージの伝達もUDPで実行される。メッセージにはカウンタがついており規定の回数再送信されるそれ以上送信されなくなる。仕様上メンバは同じメッセージを複数回受け取る可能性がある。メッセージのバッファは管理されているので同じメッセージであることは認識できる。
ゴシッププロトコルとメッセージ到達性
図4
Fanout数２、送信回数3のゴシッププロトコルのイメージ0から3の順番でうわさ話(Gossip)のようにメッセージが伝達されていく。伝達先の選択はランダムであるため、すでに受け取ったメッセージを再度受け取ったり、同じタイミングで2箇所からメッセージを受け取ることが発生する
ゴシッププロコトルというのはうわさ話(Gossip)のようにランダムな経路でメッセージを全体に伝達する方法です。ちょうど病気の感染が広がっていく様子とも一致することから感染症プロトコルなどとも呼ばれます。
ゴシッププロトコルの伝達性は1回の送信でランダムに選択する送信先の数(Fanout数)およびサーバからサーバへメッセージを(再)送信する回数で決まります。送信先の選択がランダムなのですべてのメンバにメッセージが伝わるかどうかは確率的にしか保証されません。ランダムに選択する送信先の数を増やしたり、再送信の回数を増やせばメッセージの伝達速度や全体に浸透する確率が高くなりますが、その分ネットワークの負荷が高くなります。
ゴシッププロコトルによるメッセージの伝達性や情報の収束性について厳密に評価するのは難しい問題のようです。ゴシッププロトコルによるメッセージの伝達を表すモデルはいくつかあるようですが、Serfでは簡単な感染症モデル(SIモデル)から導出される式を利用しているようです。Fanout数とクラスタの規模をパラメータとして充分な確率で全体に浸透するのに必要な再送信数を計算して決めています。
またSerfでは独自の実装としてゴシッププロトコルによるメッセージの伝達とは別に一定の間隔(デフォルトでは30秒)でランダムなメンバとのTCP通信よる保持しているクラスタの情報(メンバのステータスやタグ)の同期を行っています。
Serfの使い所
Serf
は通常のHAクラスタからメンバシップの管理およびサーバの障害検知の部分だけを取り出したようなツールになっています。P2P型の構成であることにより導入も簡単です。Serf自身ではなにかサービス等を提供できるわけでありませんが、システムにこれらの機能を簡単に追加することが可能です。- HAクラスタのような高度に連携したシステムでなくても、各サーバにserfエージェントを起動してサーバの死活確認に利用する。
- タグを利用して各サーバの役割や実行しているカーネルやアプリケーションのバージョン情報を全体で共有する。
- 仮想マシンやコンテナで構成されるクラスタのような、メンバが動的に変化するシステムでのメンバシップの管理。
- デプロイツールによってアプリケーション構成が動的に変化するシステムでの情報の共有。
まとめ
Serf はクラスタの構成をサポートするためのツールです。Serfを利用することによりサーバのメンバシップの管理や障害検知が可能になります。Serfはゴ シッププロトコル的手法を障害検知およびメッセージの伝達に利用しており、それによってP2P形式のクラスタ構成ながら、ネットワーク負荷を抑え情報のす ばやい浸透が可能になっています。ISUCON6予選をトップ通過しました
@methane です。「この技術部には問題がある！」というチーム名で @kizkoh (インフラ担当), @mecha_g3 (アプリ担当) とともに ISUCON 6 に参戦し、予選をトップスコアで通過しました。 恒例のふりかえり記事を書きます。
ふりかえり
残念ながらスコアは記録してないのですが、時系列順にやったことをまとめます。 アプリのコードは methane/isu6q-app で公開しているので、興味がある方はコードを確認してください。
strings.Replacer を使う
使用言語は最初から Go と決めていたのですが、Goの初期実装は遅すぎてタイムアウトで最初からスコア無しでした。 top でアプリのCPUが支配的なのはすぐ判りましたし、コードを読めばなにが遅いのかも一発で判りました。そんなに長くないので関数全体を張ります。
func htmlify(w http.ResponseWriter, r *http.Request, content string) string {
if content == "" {
return ""
}
rows, err := db.Query(`
SELECT * FROM entry ORDER BY CHARACTER_LENGTH(keyword) DESC
`)
panicIf(err)
entries := make([]*Entry, 0, 500)
for rows.Next() {
e := Entry{}
err := rows.Scan(&e.ID, &e.AuthorID, &e.Keyword, &e.Description, &e.UpdatedAt, &e.CreatedAt)
panicIf(err)
entries = append(entries, &e)
}
rows.Close()
keywords := make([]string, 0, 500)
for _, entry := range entries {
keywords = append(keywords, regexp.QuoteMeta(entry.Keyword))
}
re := regexp.MustCompile("("+strings.Join(keywords, "|")+")")
kw2sha := make(map[string]string)
content = re.ReplaceAllStringFunc(content, func(kw string) string {
kw2sha[kw] = "isuda_" + fmt.Sprintf("%x", sha1.Sum([]byte(kw)))
return kw2sha[kw]
})
content = html.EscapeString(content)
for kw, hash := range kw2sha {
u, err := r.URL.Parse(baseUrl.String()+"/keyword/" + pathURIEscape(kw))
panicIf(err)
link := fmt.Sprintf("<a href=\"%s\">%s</a>", u, html.EscapeString(kw))
content = strings.Replace(content, hash, link, -1)
}
return strings.Replace(content, "\n", "<br />\n", -1)
}
今回の問題ははてなキーワード＋はてなスターのようなサービスで、この関数はキーワードの紹介記事に対して他のキーワードへのリンクを生成しつつHTMLエスケープするものです。キーワードは文字数順でソートしているので、最長一致でリンクになります。
キーワードからリンクへの変換が一発でされていないのは、先に変換するとHTMLエスケープで <a> タグまでエスケープされてしまうし、逆に先にHTMLエスケープをするとキーワードを見つけられなくなるからです。（一度これに気づかず一気に変換するようにしてハマりました）
正規表現のビルドと置換のどちらがどれくらいの割合で重いのかまではまだプロファイルを始めてなかったのでわかりませんが、初手からGoらしい最適化を始めてみます。
まずGoの正規表現は遅いので strings.Replacer を使ってキーワードからリンクへの変換をします。 Replacer を構築するのにも時間がかかるので、 htmlify() という関数で毎回構築するのではなく、起動時と、キーワードの追加削除時に再構築をするようにします。（実際にはすでに存在するキーワードの記事に対する修正のケースを見逃していて無駄に再構築していました。これに気づいていたらもっとスコア上がったはず…）
var (
mKwControl sync.Mutex
kwdList KeywordArray
mKwReplacer sync.RWMutex
kwReplacer1st, kwReplacer2nd *strings.Replacer
)
func updateReplacer() {
reps1 := make([]string, 0, len(kwdList)*2)
reps2 := make([]string, 0, len(kwdList)*2)
for i, k := range kwdList {
if k.holder == "" {
k.holder = fmt.Sprintf("isuda_%x", sha1.Sum([]byte(k.Key)))
kwdList[i].holder = k.holder
}
reps1 = append(reps1, k.Key)
reps1 = append(reps1, k.holder)
reps2 = append(reps2, k.holder)
reps2 = append(reps2, k.Link)
}
r1 := strings.NewReplacer(reps1...)
r2 := strings.NewReplacer(reps2...)
mKwReplacer.Lock()
kwReplacer1st = r1
kwReplacer2nd = r2
mKwReplacer.Unlock()
}
func AddKeyword(key, link string) {
k := Keyword{Key: key, Link: link}
mKwControl.Lock()
kwdList = append(kwdList, k)
sort.Sort(kwdList)
updateReplacer()
mKwControl.Unlock()
}
func ReplaceKeyword(c string) string {
mKwReplacer.RLock()
r1 := kwReplacer1st
r2 := kwReplacer2nd
mKwReplacer.RUnlock()
x := r1.Replace(c)
x = html.EscapeString(x)
return r2.Replace(x)
}
AddKeyword はキーワードをポストしたときに、 ReplaceKeyword は htmlify から呼ばれます。これで NewReplacer を呼び出す回数を大幅に削減することができました。
この変更を投入するタイミングで、 MySQL に接続するときに '127.0.0.1' からの接続が許可されていないというエラーがでるようになって（何もしてないのに壊れた追記: 秘伝のタレでskip-name-resolveが入ったのが原因の模様） Unix Domain Socket を使うようにしました。
@kizkoh による nginx や MySQL の設定 (静的ファイルを nginx で返す等) や、初期実装にあったバグを潰したりして、14:00すぎに12万点を出しました。
isutar を isuda にマージ
これは @mecha_g3 に任せた部分です。 isutar と isuda がお互いにJSON APIを使ってやり取りをしている部分があって、2つのアプリとMySQLが1台のマシンに乗っている以上完全に無駄なので全部1つにまとめました。スコアを記録してないのですが順当に性能アップしたはずです。
これを投入してベンチをかけるときにハマったのが、DBコネクションのデッドロックです。もともと2コアの1台のマシンなので、DBへの接続は4本も要らないだろうと思いつつ、念のために8本にしていました。ところが、次のようなコードが原因で8本あっても足りなくなってしまいました。
rows, err := db.Query(fmt.Sprintf(
"SELECT * FROM entry ORDER BY updated_at DESC LIMIT %d OFFSET %d",
perPage, perPage*(page-1),
))
if err != nil && err != sql.ErrNoRows {
panicIf(err)
}
entries := make([]*Entry, 0, 10)
for rows.Next() {
e := Entry{}
err := rows.Scan(&e.ID, &e.AuthorID, &e.Keyword, &e.Description, &e.UpdatedAt, &e.CreatedAt)
panicIf(err)
e.Html = htmlify(w, r, e.Description)
e.Stars = loadStars(e.Keyword)
entries = append(entries, &e)
}
rows.Close()
このコードはトップページのハンドラーの一部です。 for rows.Next() ループが終了して rows.Close() が呼ばれるまでDBの接続を握るのですが、このループ中の loadStars(e.Keyword) の部分が中でさらにSQLを呼び出しています。
この状態で、 top ページに8個並列でアクセスが来てループの外側のクエリを実行すると、8本の接続を使い切った状態になり、どの goroutine も内側の loadStars() でDB接続を無限に待ってしまうことになります。
落ち着いて考えればすごく当たり前のことなのですが、最初は rows.Close() を呼んでない場所がどこかにあるんじゃないかと探し回ったり、この形のネストがまずいことに気づいたときも「でも1goroutineあたりのDB接続数が2倍になるだけだから、その程度の余裕は見込んで8本にしたんだけどなあ。」と考えてしまったりしてしまいました。
結果、この問題の対策もちゃんとネストを潰すのではなく、単にコネクションプールの数を倍の16に増やしただけです。ベンチマーカーがどんどん並列度上げてくるタイプだったらこれでも死んでました。
教訓として、 rows.Next() ループ内でネストしてクエリを実行するのは単に必要な接続数が倍になる以上の凶悪さを持っているので、 rows.Close() までの処理は単純にクエリ結果のフェッチだけにしましょう。
Replacer の構築を zero time cache 化
プロファイルを取ってみたところまだ Replacer の構築が重いので、個人的に zero time cache と呼んでいるイディオムを使って安全にキャッシュをしてみます。次のコードを見てください。
var (
mKwControl sync.Mutex
kwdList KeywordArray
mUpdateReplacer sync.Mutex
repLastUpdated time.Time
)
func AddKeyword(key, link string) {
k := Keyword{Key: key, Link: link}
mKwControl.Lock()
kwdList = append(kwdList, k)
mKwControl.Unlock()
updateReplacer()
}
func updateReplacer() {
now := time.Now()
mUpdateReplacer.Lock()
defer mUpdateReplacer.Unlock()
if repLastUpdated.After(now) {
return
}
repLastUpdated = time.Now()
reps1 := make([]string, 0, len(kwdList)*2)
reps2 := make([]string, 0, len(kwdList)*2)
mKwControl.Lock()
kws := kwdList[:]
mKwControl.Unlock()
sort.Sort(kws)
// ... 以降 Replacer の構築処理
}
mUpdateReplacer と repLastUpdated が追加した変数で、 updateReplacer() の repLastUpdated = time.Now() までがイディオムになっています。
例えば、キーワードA, B, C がほぼ同時に追加されたとします。
- まずAが最初にロックを取得して、
repLastUpdated = time.Now()を実行して Replacer の構築を始めます。 - 続いてキーワードBとCがともに
mUpdateReplacer.Lock()で停止します。ロック直前に取得したnowは (1) で更新したrepLastUpdatedよりも未来の時間になります。 - キーワードAの Replacer 更新が終了し、
mUpdateReplacerが開放されます。キーワードBを処理していた goroutine がそのロックを取得します。 - ロック取得前に取得した
nowがrepLastUpdatedよりも新しいので、if repLastUpdated.After(now)が真になりません。なので Replacer を再構築します。キーワードAを更新したときのkwdListにキーワードBは入っていなかった（厳密にはタイミング依存で入っていた可能性もある）ので、これは必要な処理です。 - さらにキーワードBの Replacer 更新が終わり、キーワードCが
mUpdateReplacerのロックを取得します。今度はif repLastUpdated.After(now)が真になるので、 Replacer の再構築はスキップされます。 (4) で Replacer を再構築したときには確実にキーワードCもkwdListに入っていたので、スキップしても安全です。
この説明を一度読んだだけでは理解できないかもしれませんが、ぜひじっくりとコードと見比べて理解してみてください。 このイディオムはISUCONだけではなく、実際にGoで高性能なサーバーを書くときに大変便利です。
また、例えば MySQL が複数のトランザクションを一度の fsync でコミットするグループコミットなど、「同時に実行される重い処理をバッチ化する」というのは並列処理のデザインパターンと呼んでも良いくらい汎用的だと思うのですが、どなたかこのパターンの名前をご存知でしたら @methane 宛の Tweet などで教えてください。
仕上げ
まだ top ページのハンドラーが重かったので、再び zero time cache パターンを使ってさらにトップページの内容の取得を効率化します。
ただしこのときは効率より実装の手早さを優先して、 zero time cache パターンをトップページのハンドラ内に直接実装してしまいました。着実には性能向上しましたが、これもキーワードの更新側に処理を持っていけばもっと劇的な性能向上が見込めたはずです。
最後に、アプリの環境変数で GOGC=400 を設定し、プロファイルやモニタリングやnginxのアクセスログを切り、ベストスコアを出すまで enqueue を数回実行して終了しました。
考察
POST /keyword のアクセスがキーワードの追加だけではなく更新にも使われていることを見逃していて、一番重い Replacer の再構築を必要以上に実行してしまっていたのが悔やまれます。
また、上に書いたようにトップページの内容の更新も、 GET / ではなく POST /keyword で行えばもっと劇的なスコアアップができたでしょう。
さらに、非ログインユーザーのトップページを静的ファイルに書き出してしまって nginx に直接返させるのも、ISUCONで頻出の攻略法で事前に判っていたはずで、実装する時間もあったはずなのにやるタイミングを逸してしまいました。
これらを全部できていれば、ベンチマーカーの実装次第ですが、倍の50万点の可能性もあったかもしれません。
感想
今までは毎年予選は一人で戦って勝ち抜いてきたのですが、去年の予選のボリュームが本戦と同じくらいあってキツかったので、今年は予選からチームで戦うことにしました。
「直したはずのバグがこっちのブランチでは直ってなかった」「プロファイルが違う場所のバイナリ／ソースを参照してたかもしれなくてくてアテにならない」系のトラブルはあったものの、自分がアプリを書くときに心配事を忘れて集中できたり、逆に実装を任せてる間に自分は休憩したり落ち着いて見直しをしたりできて、精神的な負荷が大幅に減り、余裕を持って優雅に戦えたと思います。
一方で、Azureに慣れていなかったことや、14時過ぎに取った初めての0点以外のスコアがその時点の断トツトップで、そこからもほぼずっと2位のダブルスコアをキープしていたこともあって、保守的になりすぎて全力を出し切れたとは言い難いです。
本戦では全力を出せるように、もう少しチームワーク練習や環境構築の練習を重ねて行きます。
それでは、決勝進出者のみなさん、決勝でお会いしましょう。 運営・出題者のみなさんはお疲れ様でした。決勝も引き続きお願いいたします。
既成の BLE デバイスを自作プログラムから利用する試み
- BLE デバイス間の通信内容をパケットレベルで読み解いてみる
題材には低価格で出回っているありふれた Anti-Lost 系 BLE デバイス A を選びました。この小さなデバイスには LED・ブザーと押しボタンスイッチが 実装されており、対向スマホアプリとの間で双方向のやりとりが可能なつくりになっています。
デバイス A の UI
デバイス A とアプリの連携に必要な処理
前回の記事から、デバイス A とアプリの連携に関する要素をピックアップしてみます。
- アプリからデバイス A の LED・ブザーをコントロール
- 「Scene 6: アプリからデバイス A の LED・ブザーを操作」
Frame 616
対向アプリ上の所定のボタンを押下すると、Frame 345, Frame 238 の示す、 "「Immediate Alert」サービス配下の「Alert Level」キャラクタリスティック" の Value Handle 0x0025 に値「2（High Alert）」が書き込まれる
デバイス A の LED・ブザーはファームウェアレベルでこの Alert Level キャラクタリスティックに紐づけられている模様。High Alert 値が書き込まれるとそれに反応して短時間 LED とブザーが ON になる
- 「Scene 6: アプリからデバイス A の LED・ブザーを操作」
- デバイス A のボタン押下をアプリへ通知
- 「Scene 5: デバイス A ボタン押下時のアプリへの通知を設定」
Frame 491
Frame 453、Frame 439、Frame 453 の示す通り、ハンドル 0x0036 は、 "ユーザ定義サービス 1（UUID = 0xFFE0）配下のユーザ定義キャラクタリスティック（UUID = 0xFFE1）配下の Client Characteristic Configuration Descriptor (CCCD)" である
当該ユーザ定義キャラクタリスティック（UUID = 0xFFE1）のプロパティには Notify が設定されており、クライアントである対向アプリから CCCD 0x0036 に Notification bit (0x0001) を書き込んでおくことで、このキャラクタリスティックの値が更新された時に Value Handle である 0x0035 経由でアプリ側へ通知（Notification）が行われるようになる
- 「Scene 7: デバイス A のボタンを押すとアプリへ通知」
Frame 711
デバイス A の物理ボタンはファームウェアレベルで Frame 439 の示す "ユーザ定義サービス 1（UUID = 0xFFE0）配下のユーザ定義キャラクタリスティック（UUID = 0xFFE1）" に紐づけられている模様。このボタンを押すと当該キャラクタリスティックの値がデバイス内部で更新され Frame 491 での仕込みに基づきアプリ側へ通知が行われる
- 「Scene 5: デバイス A ボタン押下時のアプリへの通知を設定」
サービス・キャラクタリスティック・デスクリプタの UUID について
BLE ネイティブの世界では所定のキャラクタリスティックやデスクリプタの I/O には各エントリに紐づけられたハンドルが使用されますが、抽象化された Android API での処理対象はオブジェクトです。所定のキャラクタリスティックやデスクリプタのオブジェクトの取得にはそれぞれの UUID が必要であるため、プログラムの記述に際しては、パケットログ上に記録された所定のハンドルがどの UUID のエントリのものであるかを正確に把握する必要があります。
また、サービス - キャラクタリスティック - デスクリプタは階層関係にあるため、所定のエントリのオブジェクトを取得する手続きは最上位にあるサービスのオブジェクトが常に起点となります。
以下に、パケットログから所定のサービス以下の各エントリの UUID を見つける方法と、各 UUID からそれぞれのエントリのオブジェクトを取得する Android コードの例を示します。
パケットログから所定のサービス以下の各エントリの UUID を拾う
- 前回記事中のパケットログ Frame 229 では 0x0001 - 0xffff のハンドル空間を対象に Read By Group Type Request で GATT Primary Service Declaration を照会、そのレスポンスが Frame 231 です
（クリックで大きく表示）
ここではレスポンスに含まれる 3件のレコードのうち 2件めに注目してみます
Opcode: Read By Group Type Response (0x11) : Attribute Data, Handle: 0x000c, Group End Handle: 0x000f Handle: 0x000c Group End Handle: 0x000f Value: 0118 :- Primary Service Declaration の照会に対する Read By Group Type Response の「Value」には当該サービスの UUID が格納される
- この例では 16ビット UUID = 0x1801 であり、これは、BLE 既定の Generic Attribute サービスを示す
- 当該サービスはハンドルグループ 0x000c - 0x000f を占有する
- Frame 287 では上記のハンドルグループ 0x000c - 0x000f を対象に Read By Type Request で GATT Characteristic Declaration を照会、そのレスポンスが Frame 289 です
（クリックで大きく表示）
レスポンスに注目します
Opcode: Read By Type Response (0x09) : Attribute Data, Handle: 0x000d Handle: 0x000d Value: 200e00052a- Characteristic Declaration の照会に対する Read By Type Response の「Value」には当該キャラクタリスティックのプロパティ・Value Handle・UUID が格納される（詳細：1a, 2a, 1b）
（※表は BLUETOOTH SPECIFICATION Version 4.2 [Vol 3, Part G] page 532 より） - ここでは「value: 200e00052a」につき、プロパティ = 0x20 (Indicate), Characteristic Value Handle = 0x000e, 16ビット UUID = 0x2A52
- 16ビット UUID = 0x2A52 は、BLE 既定の Service Changed キャラクタリスティックを示す
- Characteristic Declaration の照会に対する Read By Type Response の「Value」には当該キャラクタリスティックのプロパティ・Value Handle・UUID が格納される（詳細：1a, 2a, 1b）
- Frame 302 では残りのハンドル 0x000f についての情報を GATT へ Find Information Request で照会、そのレスポンスが Frame 305 です
（クリックで大きく表示）
レスポンスに注目します
Opcode: Find Information Response (0x05) UUID Format: 16-bit UUIDs (0x01) Handle: 0x000f UUID: Client Characteristic Configuration (0x2902)
- ハンドル 0x000f は Client Characteristic Configuration Descriptor (CCCD) であり、この CCCD は直前の Indicate プロパティを持つ Service Changed キャラクタリスティックに属する
（※CCCD の 16ビット UUID は 0x2902 固定）
- ハンドル 0x000f は Client Characteristic Configuration Descriptor (CCCD) であり、この CCCD は直前の Indicate プロパティを持つ Service Changed キャラクタリスティックに属する
以上のことから、デバイス A 上の Generic Attribute サービスの構成は以下の内容であることがわかります。
Generic Attribute サービス（UUID = 0x1801）
| Handle Group = 0x000c - 0x000f
|
+-- Service Changed キャラクタリスティック（UUID = 0x2A52）
| Handle = 0x000d, Value Handle = 0x000e
|
+-- Client Characteristic Configuration Descriptor (UUID = 0x2902）
Handle = 0x000f
所定の UUID のエントリのオブジェクトを取得する
ここまでに登場した UUID はすべて 16ビット値でしたが、16 ビット UUID は Bluetooth 用にアサインされている本来の 128ビット UUID の固定部分（BASE_UUID）を省略した表現です。
- BLUETOOTH SPECIFICATION Version 4.2 [Vol 3, Part B] page 227
2.5 SEARCHING FOR SERVICES : 2.5.1 UUID : To reduce the burden of storing and transferring 128-bit UUID values, a range of UUID values has been pre-allocated for assignment to often-used, registered purposes. The first UUID in this pre-allocated range is known as the Bluetooth Base UUID and has the value 00000000-0000-1000-8000-00805F9B34FB, :
Android API を用いて前出の Generic Attribute サービスと Service Changed キャラクタリスティック、およびその配下の Client Characteristic Configuration Descriptor のオブジェクトを取得するコードのイメージを示します。
private BluetoothGatt mBtGatt;
private BluetoothGattCharacteristic mChServiceChanged;
private BluetoothGattDescriptor mCCCD;
// Generic Attribute サービス の UUID
private UUID mUuidSvcGenericAttribute = UUID.fromString("00001801-0000-1000-8000-00805f9b34fb");
// Service Changed キャラクタリスティックの UUID
private UUID mUuidChServiceChanged = UUID.fromString("00002a52-0000-1000-8000-00805f9b34fb");
// Client Characteristic Configuration Descriptor の UUID （固定値）
private UUID mUuidCCCD = UUID.fromString("00002902-0000-1000-8000-00805f9b34fb");
:
private BluetoothGattCallback mGattCallback = new bleGattCallback();
:
// デバイス A へ接続後、GATT の提供する各サービス以下の一覧を取得
mBtGatt.discoverServices();(mCtx, false, mGattCallback);
:
// GATT イベントハンドラ
private class bleGattCallback extends BluetoothGattCallback {
@Override
// GATT サービス一覧取得完了
public void onServicesDiscovered(BluetoothGatt gatt, int status) {
super.onServicesDiscovered(gatt, status);
// デバイス A の Generic Attribute サービスの
// Service Changed キャラクタリスティックオブジェクトを取得
BluetoothGattService svc = gatt.getService(mUuidSvcGenericAttribute);
mChServiceChanged = svc.getCharacteristic(mUuidChServiceChanged);
// Service Changed キャラクタリスティックの
// Client Characteristic Configulation Descriptor を取得
mCCCD = mChServiceChanged.getDescriptor(mUuidCCCD);
:
}
ちなみに、アプリ開発の初期に BluetoothGattCallback の onServicesDiscovered() に次の要領のコードを挿入して 各 GATT サービス配下の全エントリの UUID を階層的に出力し保存しておくと何かと便利です。
public void onServicesDiscovered(BluetoothGatt gatt, int status) {
super.onServicesDiscovered(gatt, status);
List<BluetoothGattService> serviceList = gatt.getServices();
Log.d(TAG, "onServicesDiscovered: serviceList.size=" + serviceList.size());
for (BluetoothGattService s : serviceList) {
Log.d(TAG, "onServicesDiscovered: svc uuid=" + s.getUuid().toString());
List<BluetoothGattCharacteristic> chlist = s.getCharacteristics();
Log.d(TAG, "onServicesDiscovered: chrlist.size=" + chlist.size());
for (BluetoothGattCharacteristic c : chlist) {
UUID uuid = c.getUuid();
Log.d(TAG, "onServicesDiscovered: chr uuid=" + uuid.toString());
List<BluetoothGattDescriptor> dlist = c.getDescriptors();
Log.d(TAG, "onServicesDiscovered: desclist.size=" + dlist.size());
for (BluetoothGattDescriptor d : dlist) {
Log.d(TAG, "onServicesDiscovered: desc uuid=" + d.getUuid());
}
}
}
デバイス A への接続後に上のコードを実行した際のログです。（※見やすさのためにサービスごとに改行を挿入）
当然ながら、この内容は前回採取したパケットログ内の各エントリの情報と符合しています。
作成したアプリ
以上の内容にもとづいてアプリを作成しました。ごくシンプルなものですが期待通りに動いています。
ソースコード一式
動画：動作の様子
作成した Android アプリとデバイス A の連携の様子を収めた動画です。デバイス A は UI 部分のみを露出しています。
（34秒 アラーム音あり 音量注意）
メモ：実装手順など
private BluetoothAdapter mBtAdapter; private BluetoothLeScanner mBtScanner; private BluetoothDevice mBtDevice; private BluetoothGatt mBtGatt;
1. BluetoothAdapter 〜 BluetoothLeScanner を取得
- BluetoothAdapter - developer.android.com
Represents the local device Bluetooth adapter. The BluetoothAdapter lets you perform fundamental Bluetooth tasks, such as initiate device discovery, query a list of bonded (paired) devices, instantiate a BluetoothDevice using a known MAC address, and create a BluetoothServerSocket to listen for connection requests from other devices, and start a scan for Bluetooth LE devices. : static BluetoothAdapter getDefaultAdapter() Get a handle to the default local Bluetooth adapter. - BluetoothAdapter - getBluetoothLeScanner - developer.android.com
BluetoothLeScanner getBluetoothLeScanner () Returns a BluetoothLeScanner object for Bluetooth LE scan operations.
- BluetoothLeScanner - developer.android.com
BluetoothLeScanner This class provides methods to perform scan related operations for Bluetooth LE devices. An application can scan for a particular type of Bluetooth LE devices using ScanFilter. It can also request different types of callbacks for delivering the result.
- BluetoothLeScanner - developer.android.com
mBtAdapter = BluetoothAdapter.getDefaultAdapter(); mBtScanner = mBtAdapter.getBluetoothLeScanner();
2. アドバタイジングパケットのスキャン 〜 対象とする BluetoothDevice を取得
- BluetoothLeScanner - startScan - developer.android.com
startScan void startScan (ScanCallback callback) Start Bluetooth LE scan with default parameters and no filters. The scan results will be delivered through callback. Requires BLUETOOTH_ADMIN permission. An app must hold ACCESS_COARSE_LOCATION or ACCESS_FINE_LOCATION permission in order to get results. Parameters callback ScanCallback: Callback used to deliver scan results. :
- ScanCallback - developer.android.com
- onScanResult - developer.android.com
onScanResult void onScanResult (int callbackType, ScanResult result) Callback when a BLE advertisement has been found. Parameters callbackType int: Determines how this callback was triggered. Could be one of CALLBACK_TYPE_ALL_MATCHES, CALLBACK_TYPE_FIRST_MATCH or CALLBACK_TYPE_MATCH_LOST result ScanResult: A Bluetooth LE scan result.- ScanResult - getDevice - developer.android.com
getDevice BluetoothDevice getDevice () Returns the remote bluetooth device identified by the bluetooth device address.
- ScanResult - getDevice - developer.android.com
- onScanResult - developer.android.com
private ScanCallback mScanCallback = new bleScanCallback();
:
mBtScanner.startScan(mScanCallback);
:
private class bleScanCallback extends ScanCallback {
@Override
public void onScanResult(int callbackType, ScanResult result) {
super.onScanResult(callbackType, result);
if (.......) {
mBtDevice = result.getDevice();
}
}
@Override
public void onScanFailed(int errorCode) {
super.onScanFailed(errorCode);
Log.e(TAG, "onScanFailed: err=" + errorCode);
}
}
3. デバイスへの接続
- BluetoothDevice - connectGatt - developer.android.com
BluetoothGatt connectGatt (Context context, boolean autoConnect, BluetoothGattCallback callback) Connect to GATT Server hosted by this device. Caller acts as GATT client. The callback is used to deliver results to Caller, such as connection status as well as any further GATT client operations. The method returns a BluetoothGatt instance. You can use BluetoothGatt to conduct GATT client operations. : callback BluetoothGattCallback: GATT callback handler that will receive asynchronous callbacks. :
- BluetoothGattCallback - developer.android.com
- onConnectionStateChange - developer.android.com
void onConnectionStateChange (BluetoothGatt gatt, int status, int newState) Callback indicating when GATT client has connected/disconnected to/from a remote GATT server. : newState int: Returns the new connection state. Can be one of STATE_DISCONNECTED or STATE_CONNECTED :
- onConnectionStateChange - developer.android.com
private BluetoothGattCallback mGattCallback = new bleGattCallback();
:
mBtGatt = mBtDevice.connectGatt(mCtx, false, mGattCallback);
:
private class bleGattCallback extends BluetoothGattCallback {
@Override
public void onConnectionStateChange(BluetoothGatt gatt, int status,
int newState) {
super.onConnectionStateChange(gatt, status, newState);
if (newState == BluetoothProfile.STATE_CONNECTED) {
// 接続確立 - デバイスの GATT サービス一覧の取得へ
} else if (newState == BluetoothProfile.STATE_DISCONNECTED) {
// 切断完了の処理
}
}
:
4. GATT サービス - キャラクタリスティック - デスクリプタを探索 〜 必要なオブジェクトを取得
- BluetoothGatt - discoverServices - developer.android.com
boolean discoverServices () Discovers services offered by a remote device as well as their characteristics and descriptors. This is an asynchronous operation. Once service discovery is completed, the onServicesDiscovered(BluetoothGatt, int) callback is triggered. If the discovery was successful, the remote services can be retrieved using the getServices() function. :
- BluetoothGattCallback - onServicesDiscovered - developer.android.com
void onServicesDiscovered (BluetoothGatt gatt, int status) Callback invoked when the list of remote services, characteristics and descriptors for the remote device have been updated, ie new services have been discovered. :
- BluetoothGatt - getService - developer.android.com
getService BluetoothGattService getService (UUID uuid) Returns a BluetoothGattService, if the requested UUID is supported by the remote device. This function requires that service discovery has been completed for the given device. If multiple instances of the same service (as identified by UUID) exist, the first instance of the service is returned. Requires BLUETOOTH permission. Parameters uuid UUID: UUID of the requested service Returns BluetoothGattService BluetoothGattService if supported, or null if the requested service is not offered by the remote device.
- BluetoothGattService - getCharacteristic - developer.android.com
getCharacteristic BluetoothGattCharacteristic getCharacteristic (UUID uuid) Returns a characteristic with a given UUID out of the list of characteristics offered by this service. This is a convenience function to allow access to a given characteristic without enumerating over the list returned by getCharacteristics() manually. If a remote service offers multiple characteristics with the same UUID, the first instance of a characteristic with the given UUID is returned. Parameters uuid UUID Returns BluetoothGattCharacteristic GATT characteristic object or null if no characteristic with the given UUID was found.
- BluetoothGattCharacteristic - getDescriptor - developer.android.com
getDescriptor BluetoothGattDescriptor getDescriptor (UUID uuid) Returns a descriptor with a given UUID out of the list of descriptors for this characteristic. Parameters uuid UUID Returns BluetoothGattDescriptor GATT descriptor object or null if no descriptor with the given UUID was found.
- BluetoothGattCharacteristic - getDescriptor - developer.android.com
- BluetoothGattService - getCharacteristic - developer.android.com
private BluetoothGattCharacteristic mChAlertLevel = null;
private BluetoothGattCharacteristic mChUser1 = null;
private BluetoothGattDescriptor mDescUser1 = null;
// デバイス A の提供するサービス・キャラクタリスティック群の UUID より
private UUID mUuidSvcImAlert = UUID.fromString("00001802-0000-1000-8000-00805f9b34fb");
private UUID mUuidChAlertLevel = UUID.fromString("00002a06-0000-1000-8000-00805f9b34fb");
private UUID mUuidSvcUser1 = UUID.fromString("0000ffe0-0000-1000-8000-00805f9b34fb");
private UUID mUuidChUser1 = UUID.fromString("0000ffe1-0000-1000-8000-00805f9b34fb");
// UUID for Client Characteristic Configuration Descriptor
// - BLUETOOTH SPECIFICATION Version 4.2 [Vol 3, Part G] page 537
private UUID mUuidCCCD = UUID.fromString("00002902-0000-1000-8000-00805f9b34fb");
:
private BluetoothGattCallback mGattCallback = new bleGattCallback();
:
mBtGatt.discoverServices();(mCtx, false, mGattCallback);
:
private class bleGattCallback extends BluetoothGattCallback {
@Override
// GATT サービス一覧取得完了
public void onServicesDiscovered(BluetoothGatt gatt, int status) {
super.onServicesDiscovered(gatt, status);
// デバイス A の Immediate Alert サービスの
// Alert Level キャラクタリスティックオブジェクトを取得
BluetoothGattService svc = gatt.getService(mUuidSvcImAlert);
mChAlertLevel = svc.getCharacteristic(mUuidChAlertLevel);
// デバイス A のユーザ定義サービス 1 の ユーザ定義キャラクタリスティックの
// Client Characteristic Configulation Descriptor を取得
svc = gatt.getService(mUuidSvcUser1);
mChUser1 = svc.getCharacteristic(mUuidChUser1);
mDescUser1 = mChUser1.getDescriptor(mUuidCCCD);
:
}
5. 所定のキャラクタリスティックからの通知を有効に
- BluetoothGatt - setCharacteristicNotification - developer.android.com
boolean setCharacteristicNotification ( BluetoothGattCharacteristic characteristic, boolean enable) Enable or disable notifications/indications for a given characteristic. Once notifications are enabled for a characteristic, a onCharacteristicChanged(BluetoothGatt, BluetoothGattCharacteristic) callback will be triggered if the remote device indicates that the given characteristic has changed. Requires BLUETOOTH permission. Parameters characteristic BluetoothGattCharacteristic: The characteristic for which to enable notifications enable boolean: Set to true to enable notifications/ indications : - BluetoothGattDescriptor - setValue - developer.android.com
boolean discoverServices () setValue boolean setValue (byte[] value) Updates the locally stored value of this descriptor. This function modifies the locally stored cached value of this descriptor. To send the value to the remote device, call writeDescriptor(BluetoothGattDescriptor) to send the value to the remote device. Parameters value byte: New value for this descriptor :
- BluetoothGatt - writeDescriptor - developer.android.com
writeDescriptor boolean writeDescriptor (BluetoothGattDescriptor descriptor) Write the value of a given descriptor to the associated remote device. A onDescriptorWrite(BluetoothGatt, BluetoothGattDescriptor, int) callback is triggered to report the result of the write operation. Requires BLUETOOTH permission. Parameters descriptor BluetoothGattDescriptor: Descriptor to write to the associated remote device :
- BluetoothGatt - writeDescriptor - developer.android.com
// デバイス A への Alert 指示用
private byte[] mCmdAlertOff = new byte[] {(byte)0x00}; // OFF (No Alert)
private byte[] mCmdAlertOn = new byte[] {(byte)0x02}; // ON (High Alert)
:
// デバイス A のユーザ定義サービス 1 の ユーザ定義キャラクタリスティックの
// Client Characteristic Configulation Descriptor を取得
svc = gatt.getService(mUuidSvcUser1);
mChUser1 = svc.getCharacteristic(mUuidChUser1);
mDescUser1 = mChUser1.getDescriptor(mUuidCCCD);
// 同キャラクタリスティックの値変更時の通知を有功にして
// 同 CCCD へ ENABLE_NOTIFICATION_VALUE を書き込んで通知へ待機
mBtGatt.setCharacteristicNotification(mChUser1, true);
byte[] val = new byte[] {(byte)0x01, (byte)0x00};
mDescUser1.setValue(val);
mBtGatt.writeDescriptor(mDescUser1);
:
private class bleGattCallback extends BluetoothGattCallback {
@Override
public void onCharacteristicChanged (BluetoothGatt gatt,
BluetoothGattCharacteristic ch) {
Log.d(TAG, "onCharacteristicChanged");
// デバイス A のユーザ定義キャラクタリスティック 1 からの通知を受信
if (ch == mChUser1) {
Toast.makeText(mCtx, "* P U S H E D *", Toast.LENGTH_SHORT).show();
}
}
@Override
public void onDescriptorWrite (BluetoothGatt gatt,
BluetoothGattDescriptor desc,
int status) { // writeDescriptor() 結果
super.onDescriptorWrite(gatt, desc, status);
Log.d(TAG, "onDescriptorWrite: sts=" + status);
if (desc == mDescUser1) {
// デバイス A のユーザ定義サービス 1 の ユーザ定義キャラクタリスティックの
// Client Characteristic Configulation Descriptor への書き込みが完了
}
}
:
6. 所定のキャラクタリスティックへの書き込み
- BluetoothGattCharacteristic - setValue - developer.android.com
setValue boolean setValue (byte[] value) Updates the locally stored value of this characteristic. This function modifies the locally stored cached value of this characteristic. To send the value to the remote device, call writeCharacteristic(BluetoothGattCharacteristic) to send the value to the remote device. Parameters value byte: New value for this characteristic :
- BluetoothGatt - writeCharacteristic - developer.android.com
boolean writeCharacteristic ( BluetoothGattCharacteristic characteristic) Writes a given characteristic and its values to the associated remote device. Once the write operation has been completed, the onCharacteristicWrite(BluetoothGatt, BluetoothGattCharacteristic, int) callback is invoked, reporting the result of the operation. Requires BLUETOOTH permission. Parameters characteristic BluetoothGattCharacteristic: Characteristic to write on the remote device
- BluetoothGatt - writeCharacteristic - developer.android.com
// デバイス A への Alert 指示用
private byte[] mCmdAlertOff = new byte[] {(byte)0x00}; // OFF (No Alert)
private byte[] mCmdAlertOn = new byte[] {(byte)0x02}; // ON (High Alert)
:
mChAlertLevel.setValue(mCmdAlertOn);
mBtGatt.writeCharacteristic(mChAlertLevel);
:
private class bleGattCallback extends BluetoothGattCallback {
@Override
public void onCharacteristicWrite(BluetoothGatt gatt,
BluetoothGattCharacteristic ch,
int status) { // writeCharacteristic 結果
super.onCharacteristicWrite(gatt, ch, status);
if (ch == mChAlertLevel) {
Log.d(TAG, "mChAlertLevel: onCharacteristicWrite: sts=" + status);
}
}
:
(tanabe)
BLE デバイス間の通信内容をパケットレベルで読み解いてみる
- 技適マークつき BLE パケットスニファを入手する
BLE の通信プロトコルは複雑ですが、パケットの内容を適宜精査すれば 座学的な情報の向こう側にある実像を捉えることが可能となるでしょう。
デバイス A の UI
操作内容
デバイス A と Android 端末を使って以下の操作を行いスニファで BLE パケットのログを採取しました。
- デバイス A の電源を入れる
- Android 端末上の対向アプリからデバイスを探索しデバイス A との接続を確立
- アプリからデバイス A の LED＋ブザーを ON にする
- デバイス A のボタンを押しアプリへ通知を送る
- アプリ上でデバイス A との接続を切断
応酬の全体像
スニファの Wireshark ログより
上の操作時に収集したパケットログの全体図です。 （クリックで大きく表示）
要約
パケットログの内容の要約を以下に示します。 （クリックで大きく表示）
- デバイス A の電源を入れる
- デバイス A がアドバタイジングを開始 (ADV_IND)
- スマホ上の対向アプリからデバイスを探索しデバイス A との接続を確立
- デバイスのスキャン (SCAN_REQ / SCAN_RSP) を経て接続要求 (CONNECT_REQ) 〜接続が確立するとデバイス A はアドバタイジングを停止
- 機能情報を交換 (LL_FEATURE_REQ / LL_FEATURE_RSP)
- デバイス A の提供する GATT プライマリサービス一覧を取得
- 各サービス配下のエントリ（Included Service, キャラクタリスティック）一覧を取得
- 各キャラクタリスティック配下のデスクリプタを取得
- デバイス A のボタンが押された時に通知されるよう所定の Client Characteristic Configuration descriptor へアプリから Notification Bit 0x0001 を書き込む
- アプリからデバイス A の LED＋ブザーを ON にする
- アプリ上の所定のボタンが押されたタイミングでアプリはデバイス A の Immediate Alert サービス配下の Alert Level キャラクタリスティックへ値 2 (High Alert)を書き込む。これにより一定時間 A の LED とブザーが ON になる
- デバイス A のボタンを押しアプリへ通知を送る
- デバイス A のボタンが押されたタイミングでデバイス A は自機のユーザ定義サービス 1 (UUID=0xFFE0) 配下のユーザ定義キャラクタリスティック (UUID=0xFFE1) へ値 1 を書き込む。当該キャラクタリスティック配下の Client Characteristic Configuration descriptor にはアプリ側から予め Notification Bit がセットされているためアプリへ通知される
- アプリ上でデバイス A との接続を切断
- アプリからデバイス A へ LL_TERMINATE_IND を送る
応酬の詳細
全体の流れを見渡したところで次に個々のパケットデータを読み進めていきます。
- 以下の記事には Wireshark のスクリーンショットをログとして添えています （それぞれクリックで大きく表示）
- ログには BLE パケットデータ本体に加え nRF Sniffer が解析の便宜のためにログへ出力する「Nordic BLE sniffer meta」ヘッダが含まれています
- nRF Sniffer User Guide v1.1 (PDF) - www.nordicsemi.com Page 8 より
4 Using Wireshark All BLE packets detected by the Sniffer are passed to Wireshark and are wrapped in a header which contains useful meta-information not present in the BLE packet itself. Wireshark dissects the packets and separates the actual packet from the meta-information. :
- nRF Sniffer User Guide v1.1 (PDF) - www.nordicsemi.com Page 8 より
- 記事には下記資料からの抜粋へのリンクを参照用に適宜挿入しています
- BLUETOOTH SPECIFICATION Version 4.2 (PDF) - www.bluetooth.org
- 随所に「https://developer.bluetooth.org/gatt/」下のサービス・キャラクタリスティックの記事へのリンクを張っていますが、2016年7月頃までは参照可能だった各記事が現在はリンク切れになっており（再構成中？）、さらに現時点では代替ページが見当たらないためリンク先はやむなく http://web.archive.org/ 上のキャッシュとしています。ただし web.archive.org 上にも保存履歴のない記事については一階層上のページへのリンクを張っています
例：「Link Loss」サービスの単独ページのキャッシュは web.archive.org にも見当たらないため、上位のサービス一覧ページのキャッシュをターゲットに
局面
- Scene 1: デバイス A のアドバタイジングと SCAN_REQ / SCAN_RSP
- Scene 2: 接続の確立と情報交換
- Scene 3: デバイス A の GATT サービス群の取得
- Scene 4: デバイス A 各サービス配下のキャラクタリスティック - デスクリプタの取得
- Scene 5: デバイス A ボタン押下時のアプリへの通知を設定
- Scene 6: アプリからデバイス A の LED・ブザーを操作
- Scene 7: デバイス A のボタンを押すとアプリへ通知
- Scene 8: アプリ側からデバイス A との接続を切断
Scene 1: デバイス A のアドバタイジングと SCAN_REQ / SCAN_RSP
Frame 124 - 126 はデバイス A 発のアドバタイジングパケット
- 全 40 チャネルのうちアドバタイジングパケット用の 37, 38, 39 の 3 チャネルが順次使用されていることが見てとれる
- 「0x8e89bed6」の Access Address はアドバタイジングチャネルパケットで使用される固定値
- デバイス A のアドバタイジングのタイプは Connectable Undirected（詳細： 1, 2, 3, 4） であることを示す一般的な「ADV_IND」である
- 「Advertising Data: 020106020a000702031802180418」に含まれる不完全 16ビットサービスクラス UUID は次の内容
- 16 bit uuid: 0x1803 --> 既定の「Link Loss」サービス
- 16 bit uuid: 0x1802 --> 既定の「Immediate Alert」サービス
- 16 bit uuid: 0x1804 --> 既定の「Tx Power」サービス
|
Frame 124
|
Frame 125
|
Frame 126
|
接続に際し対向アプリがデバイス A に対して SCAN_REQ を発行
デバイス A が対向アプリからの SCAN_REQ に対し SCAN_RSP を返信。ここでは ScanRspData としてデバイスのローカルネームが渡されている
Scene 2: 接続の確立と情報交換
対向アプリがデバイス A に対して CONNECT_REQ（詳細：1a, 2a, 1b, 2b）を発行して接続を試みる
- 「Connection Request」中の「Connection Access Address」には、接続確立後のデータ通信において Access Address として双方が一意に使用する任意のアドレスが含まれる。ここでは「0xa6a188c8」
- 「Connection Request」中の「Channel map」には接続確立後のデータ通信で使用するチャネル番号のリストが提示される。ここでは 0 - 36 の全データチャネルが指定されている
- その他のパラメータについては上のリンクの資料を参照のこと
- CONNECT_REQ に対する直接のレスポンスは発生しない。接続が確立するとデータ通信アイドル時にスレーブ - マスタ間で空パケット（Empty PDU）の応酬が始まるためこれが接続成否の判定に用いられる
Frame 218, 224 は接続確立後の最初の応酬。接続が確立すると対向アプリはマスタ、デバイス A はスレーブの位置づけとなる。ここでは リンク層制御 PDU の LL_FEATURE_REQ および LL_FEATURE_RSP によりマスタ - スレーブ間で Feature Exchange を行っている。ここでは双方とも「Supported feature: LE Encryption (0)」のみを提示（ただしここでは以降の通信において暗号化は行われていない）
|
Frame 218
|
Frame 224
|
Frame 222 ではアプリ側が「Device Name」を要求し Frame 226 でデバイス A 側がそれに応えている。
「Device Name」は、既定の Generic Access（GAP）サービス配下の既定のキャラクタリスティック（UUID = 0x2A00）であり、GATT サーバは必ず GAP サービスを含んでいる（詳細：1, 2）
（GAP サービスおよび Device Name キャラクタリスティックは後続の Frame 231, Frame 266 であらためて表に現れる）
Scene 3: デバイス A の GATT サービス群の取得
（Scene 3, Scene 4 共通の基礎知識）
BLUETOOTH SPECIFICATION Version 4.2(PDF) [Vol 3, Part G] より
2.6 GATT PROFILE HIERARCHY
2.6.1 Overview, 2.6.2 Service, 2.6.3 Included Services, 2.6.4 Characteristic
3 SERVICE INTEROPERABILITY REQUIREMENTS
3.1 SERVICE DEFINITION, 3.2 INCLUDE DEFINITION, 3.3 CHARACTERISTIC DEFINITION
3.3.1 Characteristic Declaration
3.3.1.1 Characteristic Properties, 3.3.1.2 Characteristic Value Attribute Handle, 3.3.1.3 Characteristic UUID
3.3.2 Characteristic Value Declaration
初期処理として、マスタはスレーブの提供するサービス一覧を取得する （詳細：1, 2, 3）
- アプリ側が、デバイス A の GATT サーバの提供する公開サービス（プライマリサービス）の問合せを開始。 以降、GATT サーバ上の所定のサービスへアクセスするためのハンドルのアドレスと当該サービスの種類を識別する UUID を順次取得する
- ハンドルのアドレス空間は 0x0000 - 0xFFFF であり GATT サーバ側の応答に応じて照会範囲を絞っていく
（図は 「BLUETOOTH SPECIFICATION Version 4.2」 より引用）
まずハンドル 0x0001 - 0xffff 全範囲についてプライマリサービスを照会
Opcode: Read By Group Type Request (0x10)
Starting Handle: 0x0001
Ending Handle: 0xffff
UUID: GATT Primary Service Declaration (0x2800)
以下のみっつのサービスの情報が得られた
- ハンドルグループ 0x0001 - 0x000b：既定の「Generic Access」サービス（UUID = 0x1800）が使用
- ハンドルグループ 0x000c - 0x000f：既定の「Generic Attribute」サービス（UUID = 0x1801）が使用
- ハンドルグループ 0x0010 - 0x0022：既定の「Device Information」サービス（UUID = 0x180A）が使用
Opcode: Read By Group Type Response (0x11)
Length: 6
Attribute Data, Handle: 0x0001, Group End Handle: 0x000b
Handle: 0x0001
Group End Handle: 0x000b
Value: 0018
Attribute Data, Handle: 0x000c, Group End Handle: 0x000f
Handle: 0x000c
Group End Handle: 0x000f
Value: 0118
Attribute Data, Handle: 0x0010, Group End Handle: 0x0022
Handle: 0x0010
Group End Handle: 0x0022
Value: 0a18
続けてハンドル 0x0023 - 0xffff 範囲のプライマリサービスを照会
以下のみっつのサービスの情報が得られた
- ハンドルグループ 0x0023 - 0x0025：既定の「Immediate Alert」サービス（UUID = 0x1802）が使用
- ハンドルグループ 0x0026 - 0x002a：既定の「Tx Power」サービス（UUID = 0x1804）が使用
- ハンドルグループ 0x002b - 0x002d：既定の「Link Loss」サービス（UUID = 0x1803）が使用
続けてハンドル 0x002e - 0xffff 範囲のプライマリサービスを照会
以下のみっつのサービスの情報が得られた
- ハンドルグループ 0x002e - 0x0032：既定の「Battery Service」サービス（UUID = 0x180F）が使用
- ハンドルグループ 0x0033 - 0x0037：ユーザ定義のサービス 1（UUID = 0xFFE0）が使用
- ハンドルグループ 0x0038 - 0x003a：ユーザ定義のサービス 2（UUID = 0xFFF0）が使用
続けてハンドル 0x003b - 0xffff 範囲のプライマリサービスを照会
「Attribute Not Found (0x0a)」のエラーが返る。これ以上プライマリサービスが存在しないことを意味する。サービスの照会はここまで
Opcode: Error Response (0x01)
Request Opcode in Error: Read By Group Type Request (0x10)
Handle in Error: 0x003b
Error Code: Attribute Not Found (0x0a)
Scene 4: デバイス A 各サービス配下のキャラクタリスティック - デスクリプタの取得
（Scene 3, Scene 4 共通の基礎知識）
BLUETOOTH SPECIFICATION Version 4.2(PDF) [Vol 3, Part G] より
2.6 GATT PROFILE HIERARCHY
2.6.1 Overview, 2.6.2 Service, 2.6.3 Included Services, 2.6.4 Characteristic
3 SERVICE INTEROPERABILITY REQUIREMENTS
3.1 SERVICE DEFINITION, 3.2 INCLUDE DEFINITION, 3.3 CHARACTERISTIC DEFINITION
3.3.1 Characteristic Declaration
3.3.1.1 Characteristic Properties, 3.3.1.2 Characteristic Value Attribute Handle, 3.3.1.3 Characteristic UUID
3.3.2 Characteristic Value Declaration
次に、収集ずみの各プライマリサービスのハンドルグループごとに以下を行う （詳細：1, 2, 3, 4, 5, 6）
- 所定のサービスに含まれる Included Service の照会
（図は 「BLUETOOTH SPECIFICATION Version 4.2」 より引用） - 所定のサービスに含まれるキャラクタリスティックの照会
（図は 「BLUETOOTH SPECIFICATION Version 4.2」 より引用）- 所定のキャラクタリスティックに含まれるデスクリプタの照会
（図は 「BLUETOOTH SPECIFICATION Version 4.2」 より引用）
- 所定のキャラクタリスティックに含まれるデスクリプタの照会
前掲の Frame 231 の示すハンドルグループ 0x0001 - 0x000b の「Generic Access」サービス内の Included Service を照会
Opcode: Read By Type Request (0x08)
Starting Handle: 0x0001
Ending Handle: 0x000b
UUID: GATT Include Declaration (0x2802)
当該サービス内に Included Service は存在しない（注：図のログではスニファがパケットデータを取りこぼしている）
ハンドルグループ 0x0001 - 0x000b の「Generic Access」サービス内のキャラクタリスティックを照会
Opcode: Read By Type Request (0x08)
Starting Handle: 0x0001
Ending Handle: 0x000b
UUID: GATT Characteristic Declaration (0x2803)
以下のみっつのキャラクタリスティックの情報が得られた
（※キャラクタリスティック の Value フィールドの構成は前掲の「BLUETOOTH SPECIFICATION Version 4.2] - [Vol 3, Part G] p.532 「3.3.1 Characteristic Declaration」 に、プロパティ値の意味は同じく p.533 「3.3.1.1 Characteristic Properties」 に説明あり）
- ハンドル：0x0002
「value: 080300002a」より、プロパティ = 0x08 (Write), Characteristic Value Handle = 0x0003
UUID = 0x2A00 = 既定の「Device Name」 - ハンドル：0x0004
「value: 020500012a」より、プロパティ = 0x02 (Read), Characteristic Value Handle = 0x0005
UUID = 0x2A01 = 既定の「Appearance」 - ハンドル：0x0006
「value: 020700042a」より、プロパティ = 0x02 (Read), Characteristic Value Handle = 0x0007
UUID = 0x2A04 = 既定の「Peripheral Preferred Connection Parameters」
Opcode: Read By Type Response (0x09)
Length: 7
Attribute Data, Handle: 0x0002
Handle: 0x0002
Value: 080300002a
Attribute Data, Handle: 0x0004
Handle: 0x0004
Value: 020500012a
Attribute Data, Handle: 0x0006
Handle: 0x0006
Value: 020700042a
続けてハンドル 0x0007 - 0x000b 範囲のキャラクタリスティックを照会
以下のふたつのキャラクタリスティックの情報が得られた
- ハンドル：0x0008
「value: 020900022a」より、プロパティ = 0x02 (Read), Characteristic Value Handle = 0x0009
UUID = 0x2A02 = 既定の「Peripheral Privacy Flag」 - ハンドル：0x000a
「value: 020b00032a」より、プロパティ = 0x02 (Read), Characteristic Value Handle = 0x000b
UUID = 0x2A03 = 既定の「Reconnection Address」
前掲の Frame 231 の示すハンドルグループ 0x000c - 0x000f の「Generic Attribute」サービス内の Included Service を照会
当該サービス内に Included Service は存在しない
ハンドルグループ 0x000c - 0x000f の「Generic Attribute」サービス内のキャラクタリスティックを照会
以下のキャラクタリスティックの情報が得られた
- ハンドル：0x000d
「value: 200e00052a」より、プロパティ = 0x20 (Indicate), Characteristic Value Handle = 0x000e
UUID = 0x2A52 = 既定の「Service Changed」
続けてハンドル 0x000e - 0x000f 範囲のキャラクタリスティックを照会
当該サービス内にはこれ以上キャラクタリスティックは存在しない
Frame 289 の示す通り 0x0000e は Service Changed キャラクタリスティックの Value Handle であり、残る0x000f に関する情報を GATT に問い合わせてみる （詳細：1, 2）
Opcode: Find Information Request (0x04)
Starting Handle: 0x000f
Ending Handle: 0x000f
0x000f は Service Changed キャラクタリスティックの Client Characteristic Configuration Descriptor (UUID = 0x2902） （詳細：1, 2） である旨の情報が得られた
Opcode: Find Information Response (0x05)
UUID Format: 16-bit UUIDs (0x01)
Handle: 0x000f
UUID: Client Characteristic Configuration (0x2902)
前掲の Frame 231 の示すハンドルグループ 0x0010 - 0x0022 の「Device Information」サービス内の Included Service を照会
当該サービス内に Included Service は存在しない
ハンドルグループ 0x0010 - 0x0022 の「Device Information」サービス内のキャラクタリスティックを照会
以下のみっつのキャラクタリスティックの情報が得られた
- ハンドル：0x00011
「value: 021200292a」より、プロパティ = 0x02 (Read), Characteristic Value Handle = 0x0012
UUID = 0x2A29 = 既定の「Manufacturer Name String」 - ハンドル：0x00013
「value: 021400242a」より、プロパティ = 0x02 (Read), Characteristic Value Handle = 0x0014
UUID = 0x2A24 = 既定の「Model Number String」 - ハンドル：0x00015
「value: 021600252a」より、プロパティ = 0x02 (Read), Characteristic Value Handle = 0x0014
UUID = 0x2A25 = 既定の「Serial Number String」
続けてハンドル 0x0016 - 0x0022 範囲のキャラクタリスティックを照会
以下のみっつのキャラクタリスティックの情報が得られた
- ハンドル：0x00017
「value: 021800262a」より、プロパティ = 0x02 (Read), Characteristic Value Handle = 0x0018
UUID = 0x2A26 = 既定の「Firmware Revision String」 - ハンドル：0x00019
「value: 021a00272a」より、プロパティ = 0x02 (Read), Characteristic Value Handle = 0x001a
UUID = 0x2A27 = 既定の「Hardware Revision String」 - ハンドル：0x0001b
「value: 021c00282a」より、プロパティ = 0x02 (Read), Characteristic Value Handle = 0x001c
UUID = 0x2A28 = 既定の「Software Revision String」
続けてハンドル 0x001c - 0x0022 範囲のキャラクタリスティックを照会
以下のみっつのキャラクタリスティックの情報が得られた
- ハンドル：0x0001d
「value: 021e00232a」より、プロパティ = 0x02 (Read), Characteristic Value Handle = 0x001e
UUID = 0x2A23 = 既定の「System ID」 - ハンドル：0x0001f
「value: 0220002a2a」より、プロパティ = 0x02 (Read), Characteristic Value Handle = 0x0020
UUID = 0x2A2A = 既定の「IEEE 11073-20601 Regulatory Certification Data List」 - ハンドル：0x00021
「value: 022200502a」より、プロパティ = 0x02 (Read), Characteristic Value Handle = 0x0022
UUID = 0x2A50 = 既定の「PnP ID」
前掲の Frame 238 の示すハンドルグループ 0x0023 - 0x0025 の「Immediate Alert」サービス内の Included Service を照会
（注：このリクエストに対する正しいレスポンスは「Attribute Not Found (0x0a)」だが、スニファ取りこぼしのためログが欠落している）
ハンドルグループ 0x0023 - 0x0025 の「Immediate Alert」サービス内のキャラクタリスティックを照会
以下のキャラクタリスティックの情報が得られた
- ハンドル：0x0024
「value: 042500062a」より、
プロパティ = 0x04 (Write without Response),
Characteristic Value Handle = 0x0025
UUID = 0x2A06 = 既定の「Alert Level」
前掲の Frame 238 の示すハンドルグループ 0x0026 - 0x002a の「Tx Power」サービス内の Included Service を照会
（注：このリクエストに対する正しいレスポンスは「Attribute Not Found (0x0a)」だが、スニファ取りこぼしのためログが欠落している）
ハンドルグループ 0x0026 - 0x002a の「Tx Power」サービス内のキャラクタリスティックを照会
以下のキャラクタリスティックの情報が得られた
- ハンドル：0x0027
「value: 122800072a」より、プロパティ = 0x12 (Read | Notify), Characteristic Value Handle = 0x0028
UUID = 0x2A07 = 既定の「Tx Power Level」
続けてハンドル 0x0028 - 0x002a 範囲のキャラクタリスティックを照会
当該サービス内にはこれ以上キャラクタリスティックは存在しない
Frame 359 の示す通り 0x00028 は Tx Power Level キャラクタリスティックの Value Handle であり後続の 0x0029 - 0x002a に関する情報を GATT に問い合わせてみる （詳細：1, 2）
0x0029 は Tx Power Level キャラクタリスティックの Client Characteristic Configuration Descriptor (UUID = 0x2902） （詳細：1, 2） である旨の情報が得られた
残る0x002a に関する情報を GATT に問い合わせてみる （詳細：1, 2）
0x002a は Tx Power Level キャラクタリスティックの Characteristic Presentation Format Descriptor (UUID = 0x2904） （詳細：1, 2, 3, 4） である旨の情報が得られた
Opcode: Find Information Response (0x05)
UUID Format: 16-bit UUIDs (0x01)
Handle: 0x002a
UUID: Characteristic Presentation Format (0x2904)
前掲の Frame 238 の示すハンドルグループ 0x002b - 0x002d の「Link Loss」サービス内の Included Service を照会
（注：このリクエストに対する正しいレスポンスは「Attribute Not Found (0x0a)」だが、スニファ取りこぼしのためログが欠落している）
ハンドルグループ 0x002b - 0x002d の「Link Loss」サービス内のキャラクタリスティックを照会
以下のキャラクタリスティックの情報が得られた
- ハンドル：0x002c
「value: 0a2d00062a」より、プロパティ = 0x0a (Read | Write), Characteristic Value Handle = 0x002d
UUID = 0x2A06 = 既定の「Alert Level」
前掲の Frame 247 の示すハンドルグループ 0x002e - 0x0032 の「Battery Service」サービス内の Included Service を照会
当該サービス内に Included Service は存在しない
ハンドルグループ 0x002e - 0x0032 の「Battery Service」サービス内のキャラクタリスティックを照会
以下のキャラクタリスティックの情報が得られた
- ハンドル：0x002f
「value: 123000192a」より、プロパティ = 0x12 (Read | Notify), Characteristic Value Handle = 0x0030
UUID = 0x2A19 = 既定の「Battery Level」
続けてハンドル 0x0030 - 0x0032 範囲のキャラクタリスティックを照会
当該サービス内にこれ以上キャラクタリスティックは存在しない
Frame 404 の示す通り 0x00030 は Battery Level キャラクタリスティックの Value Handle であり後続の 0x0031 - 0x0032 に関する情報を GATT に問い合わせてみる （詳細：1, 2）
0x0031 は Battery Level キャラクタリスティックの Client Characteristic Configuration Descriptor (UUID = 0x2902） （詳細：1, 2） である旨の情報が得られた
残る0x0032 に関する情報を GATT に問い合わせてみる （詳細：1, 2）
0x0032 は Battery Level キャラクタリスティックの Characteristic Presentation Format Descriptor (UUID = 0x2904） （詳細：1, 2, 3, 4） である旨の情報が得られた
前掲の Frame 247 の示すハンドルグループ 0x0033 - 0x0037 のユーザ定義サービス 1（UUID = 0xFFE0）内の Included Service を照会
当該サービス内に Included Service は存在しない
ハンドルグループ 0x0033 - 0x0037 のユーザ定義サービス 1 内のキャラクタリスティックを照会
以下のキャラクタリスティックの情報が得られた
- ハンドル：0x0034
「value: 103500e1ff」より、
プロパティ = 0x10 (Notify),
Characteristic Value Handle = 0x0035
UUID = 0xFFE1 : ユーザ定義のキャラクタリスティック
続けてハンドル 0x0035 - 0x0037 範囲のキャラクタリスティックを照会
当該サービス内にこれ以上キャラクタリスティックは存在しない
Frame 439 の示す通り 0x00035 はユーザ定義キャラクタリスティック（UUID = 0xFFE1）の Value Handle であり後続の 0x0036 - 0x0037 に関する情報を GATT に問い合わせてみる （詳細：1, 2）
0x0036 はユーザ定義キャラクタリスティック（UUID = 0xFFE1）の Client Characteristic Configuration Descriptor (UUID = 0x2902） （詳細：1, 2） である旨の情報が得られた
残る0x0037 に関する情報を GATT に問い合わせてみる （詳細：1, 2）
0x0037 はユーザ定義キャラクタリスティック（UUID = 0xFFE1）の Characteristic User Description Descriptor (UUID = 0x2901）である旨の情報が得られた
前掲の Frame 247 の示すハンドルグループ 0x0038- 0x003a のユーザ定義サービス 2（UUID = 0xFFF0）内の Included Service を照会
当該サービス内に Included Service は存在しない
ハンドルグループ 0x0038 - 0x003a のユーザ定義サービス 2 内のキャラクタリスティックを照会
以下のキャラクタリスティックの情報が得られた
- ハンドル：0x0039
「value: 043a00f1ff」より、プロパティ = 0x04 (Write without Response), Characteristic Value Handle = 0x003a
UUID = 0xFFF1 : ユーザ定義のキャラクタリスティック
Scene 5: デバイス A ボタン押下時のアプリへの通知を設定
Frame 453、Frame 439、Frame 453 の示す通り、ハンドル 0x0036 は、 "ユーザ定義サービス 1（UUID = 0xFFE0）配下のユーザ定義キャラクタリスティック（UUID = 0xFFE1）配下の Client Characteristic Configuration Descriptor (CCCD)" である
当該ユーザ定義キャラクタリスティック（UUID = 0xFFE1）のプロパティには Notify が設定されており、クライアントである対向アプリから CCCD 0x0036 に Notification bit (0x0001) を書き込んでおくことで、このキャラクタリスティックの値が更新された時に Value Handle である 0x0035 経由でアプリ側へ通知（Notification）が行われるようになる
（詳細：
1a,
2a,
1b,
2b）
Opcode: Write Request (0x12)
Handle: 0x0026
Value: 0100
Opcode: Write Response (0x13)
Scene 6: アプリからデバイス A の LED・ブザーを操作
対向アプリ上の所定のボタンを押下すると、Frame 345, Frame 238 の示す、 "「Immediate Alert」サービス配下の「Alert Level」キャラクタリスティック" の Value Handle 0x0025 に値「2（High Alert）」が書き込まれる
デバイス A の LED・ブザーはファームウェアレベルでこの Alert Level キャラクタリスティックに紐づけられている模様。High Alert 値が書き込まれるとそれに反応して短時間 LED とブザーが ON になる
なお、Frame 345 の示すように Alert Level キャラクタリスティックのプロパティには「Write without Response」(0x04) が設定されているため、アプリから値を書き込んでもデバイス A からのレスポンスは発生しない
Opcode: Write Command (0x52)
Handle: 0x0025
Value: 02
Scene 7: デバイス A のボタンを押すとアプリへ通知
デバイス A の物理ボタンはファームウェアレベルで Frame 439 の示す "ユーザ定義サービス 1（UUID = 0xFFE0）配下のユーザ定義キャラクタリスティック（UUID = 0xFFE1）" に紐づけられている模様。このボタンを押すと当該キャラクタリスティックの値がデバイス内部で更新され Frame 491 での仕込みに基づきアプリ側へ通知が行われる
Opcode: Handle Value Notification (0x1b)
Handle: 0x0035
Value: 01
Scene 8: アプリ側からデバイス A との接続を切断
対向アプリ上の所定のボタンを押下するとリンク層制御 PDU の LL_TERMINATE_IND (0x02) がデバイス A 側に送出され両者間の接続が終了する（詳細：1, 2）
(tanabe)
pixiv private isucon 2016 Python 版実装を用意しました
今年の ISUCON でも Python 実装が提供されることが 発表されました。
Python での練習は過去の予選問題でも可能ですが、今年の出題チームが準備した問題で 練習できるように Python 版の実装を用意しました。とりあえずベンチマーカーが完走する ところまでは確認してあります。
用意したのはアプリの実装だけなので、これを使って練習する際は
pixiv さんが公開されている AMI
の webapp ディレクトリ配下に python という名前で git clone し、
systemd などの設定は練習の一環として自前で行ってください。
また時間があるときに自分でチューニングしてみて、ミドルウェアの選定や ツール・テクニックなどを公開したいと思います。
@methane
技適マークつき BLE パケットスニファを入手する
国内では次のような BLE プロトコルアナライザが販売されています。もっともこういった数百万円オーダーの専用機にはなかなか手を出せません。
もっと手軽な方法として、BLE チップ・モジュールベンダの提供するパケットスニファを利用する選択があります。代表的な製品をピックアップしてみます。
- nRF Sniffer - Nordic Semiconductor 社
- nRF51 Dongle （参考価格：$49.00）
-
nRF51 DK （参考価格：$39.00）
- nRF51 Dongle （参考価格：$49.00）
- CC2540 USB Evaluation Module Kit - Texas Instruments 社 （参考価格：$49.00）
パケットスニファと技適
たとえば、前掲の Nordic Semiconductor 社製「nRF51 Dongle」は技適証明を受けていないためディストリビュータが次のように注意を促しています。
- nRF51 USB dongle for emulator,firmware - jp.rs-online.com
警告 本開発キットは技術基準適合証明を受けておりません。本製品のご使用に際しては、 電波法遵守のため、以下のいずれかの措置を取っていただく必要がありますので ご注意ください。 - 電波法施行規則第 6 条第 1 項第 1 号に基づく平成 18 年 3 月 28 日総務省告示 第 173 号で定められた電波暗室等の試験設備内で使用する。 - 実験局の免許を取得したのち使用する。 - 技術基準適合証明を取得したのち使用する。
- 電波法 （最終改正：平成二七年五月二二日法律第二六号） - law.e-gov.go.jp
第一章 総則 : 第二条 この法律及びこの法律に基づく命令の規定の解釈に関しては、次の定義に 従うものとする。 : 五 「無線局」とは、無線設備及び無線設備の操作を行う者の総体をいう。 但し、受信のみを目的とするものを含まない。 :
- Nordic nRF51-Dongle | mbed - developer.mbed.org
以下の例のように、技適マークつきの製品においてさえ「ファームウェアの書き換え」との整合性を一意に判断できない事情を考え合わせると、技適マークなしのこれらのスニファ製品の日本国内での使用の是非はやはり微妙かもしれません。
- ESP-WROOM-02のファームウェアを書き換えた場合、技適はどうなるのか - スイッチサイエンス
ユーザーによるファームウェアの書き換えが、ESP-WROOM-02の工事設計認証を 無効にする可能性について、メーカーのEspressif Systemsに確認をしました。 同社は登録認証機関に確認した上で、Arduino core for ESP8266 WiFi chip または同社製SDKを使っている限りにおいては、認証には影響を与えないという 回答を下さいました。他の開発環境など、ファームウェアを書き換える部分に よっては、認証に影響を及ぼし得るとのことですので、ご注意ください。
- モノワイヤレス製品情報 - MONO-WIRELESS.COM - mono-wireless.com
電波法規（技適）について : 更にファームウエアを書き換えると認証の範囲を外れてしまう無線モジュール も存在しています。弊社製品は全て技適認証に適合した無線モジュールですので コンプライアンスに背くことなく安心してご使用していただけます。併せて 「電波法についての考慮事項」を参照ください。
- DD-WRT - wikipedia
電波法による規制 日本においては無線機器に対してメーカー側が想定していない非公式ファーム ウェアへの書き換えを行った時点で技適マークが無効となり、無線LANを利用する 場合は電波法に違反する[要出典]。 :
Adafruit 社製「Bluefruit LE Sniffer」
そんなわけで前掲のスニファの導入は一旦保留していましたが、情報を探しているうちにふとある製品のスペックに目がとまりました。
-
Bluefruit LE Sniffer - Bluetooth Low Energy (BLE 4.0) - nRF51822 - yeint.ee
Tehnilised andmed : - MDBT Datasheet - 18mm x 61mm x 7mm - Weight: 6.5g
- 技術基準適合証明等を受けた機器の検索 - 204-420020 - www.tele.soumu.go.jp
- Adafruit Feather 32u4 Bluefruit LE - スイッチサイエンス
BLE(Bluetooth Low Energy)機能付きの小型Arduino互換ボードです。 Adafruit Bluefruit LE Microの後継品です。 : Arduino Leonardoなどに搭載されているATmega 32u4を搭載。 BLEモジュールであるMDBT40は、総務省の工事設計認証（いわゆる技適）を 取得済みなので、日本国内で使用することができます。 :
cdn-shop.adafruit.com
このスニファであれば技適関連のジレンマなしに利用できそうです。本体価格は直販で $29.95。以下、Adafruit 社公式サイトより。
- Bluefruit LE Sniffer - Bluetooth Low Energy (BLE 4.0) - nRF51822 - v1.0 - www.adafruit.com
- Introducing the Adafruit Bluefruit LE Sniffer - learn.adafruit.com
- ホスト PC との接続が身近な FTDI ドライバで完結する
- Nordic Semiconductor が自社製品用に公開している「nRF Sniffer」プログラム（Windows 専用）＋ Wireshark のコンビネーションに対応しており扱いやすい
- Nordic nRF Sniffer - learn.adafruit.com
- nRF Sniffer - www.nordicsemi.com
- nRF Sniffer User Guide - www.nordicsemi.com
- nRF-Sniffer Download - www.nordicsemi.com
- nRF Sniffer は暗号化された BLE 通信の復号に対応
- Is nRF Sniffer doing decryption? - devzone.nordicsemi.com
- nRF Sniffer User Guide v1.1 (PDF) - www.nordicsemi.com p.10 - 11
- Mac OS X 10.9 (Mavericks) 以降では Roland King 氏による非公式の代替ソフトウェアを利用可能（手元では未検証）
- nrf-ble-sniffer-osx - sourceforge.net
- マルチプラットフォームで利用可能な独自の Python API セットが Adafruit より提供されている
- Python API - learn.adafruit.com
- GitHub: adafruit/Adafruit_BLESniffer_Python - github.com/adafruit
発送連絡後に USPS サイトで配送状況を確認すると経由地に「JAMAICA」の表記あり。さては Japan -> Jamaica のミスか？ と疑いましたがこれはカリブ海域にある国の名前ではなく JFK 空港そばの「JAMAICA, NY 11430」でした。物流の要衝のようですが恥ずかしながらニューヨークにジャマイカという地名があることを初めて知りました。Adafruit さん疑ってごめんなさい（^^；
使ってみる
Windows PC で Bluefruit LE Sniffer を使用する最短の手順を示します。詳細は nRF Sniffer アーカイブ内の「nRF Sniffer User Guide」に記載されています。
- FTDI 社の仮想 COM ポートドライバを未導入ならインストール
- Virtual COM Port Drivers - www.ftdichip.com
- 最新の nRF Sniffer の zip アーカイブをダウンロードし適当なフォルダ A へ展開
- nRF-Sniffer Download - www.nordicsemi.com
- Wireshark（v1.10.1 以降）を未導入ならインストール
- Download Wireshark - www.wireshark.org
- Bluefruit LE Sniffer を USB ポートへ接続し Sniffing の対象とするデバイスを近接させておく
図は「nRF Sniffer User Guide v1.2」より
- フォルダ A 直下の「ble-sniffer_win_<version>_Sniffer.exe」を実行
- コンソールが開きアドバタイジング中の BLE デバイスが一覧表示される
- カーソルキー＋ENTER または「＃」番号で対象とするデバイスを選択
- デバイスを選択した状態で「w」キーを押下すると Wireshark が起動。あとはデバイス側で必要な操作を行えばよい
付記：デュアルユース品と輸出規制
ご存知の方も多いと思いますが、Mouser や RS，Digi-key といった一般のディストリビュータから所定の電子部品を購入しようとすると、その製品の内容と在庫元・出荷元の国や地域によっては軍事転用の可能な「デュアルユース品目」として輸出規制に引っかかり、所定の書類一式の提出を求められ審査のために数週間程度待たされる場合があります。
今回、某ディストリビュータへ所定の商品が輸出規制の対象が否かを事前に判別する方法の有無を尋ねたところ「注文を受け実際に輸出手続きを開始しなければわからない」との回答でした。 輸出規制に関する注意書きの有無はまちまちですが、以下に一例を引用します。
-
nRF51-Dongle Nordic Semiconductor | Mouser - www.mouser.jp
This product may require additional documentation to export from the United States. この製品をアメリカから配送するには、追加の書類が必要になる ことがあります。
-
Adafruit's export process - overview - www.adafruit.com
Export Controls - Adafruit makes efforts to follow the Export Administration Regulations (EAR) and Bureau of Industry and Security (BIS) guidelines. - What is the jurisdiction of item (BIS, DDTC, ITAR) Is it subject to EAR? Does it require a license? - Adafruit makes best efforts to Export using appropriate ECCN and authorization. - Adafruit has a process for self-assigning ECCNs for its products. - Adafruit has a process for requesting ECCNs for third party products. - Most Adafruit products are subject only to AT controls or are EAR99.- 「AT」= Anti-Terrorism
- 「EAR99」= CCL（規制品目リスト）に記載のない規制対象品のカテゴリ。商務省のライセンスなしで輸出可能な場合がある
- 米国輸出規則 - Export Administration Regulations (EAR) - 在日米国大使館商務部
- スマホアプリと米国輸出規制に関するメモ - 当ブログ
- スマホアプリと米国輸出規制に関するメモの続き - 当ブログ
(tanabe)
Tomoru と Pochiru と Linking
Tomoru
Tomoru は、昨年（2015年）11月より国内のクラウドファンディングサービス Makuake で支援募集の行われた Bluetooth Low Energy（BLE）デバイスです。「Project Linking」の立ち上げとともに当時話題になったためご存知の方も多いことでしょう。2016年8月現在は製造元である株式会社 Braveridge の公式ストアや Amazon から入手することができます。以前このブログで「blink(1)」という製品をピックアップしたことがありますが、個人的に「光りもの」は好物で、この Tomoru も支援募集への応募によって届いた個体を持っています。
www.products.braveridge.com
現時点では対応アプリが全体的にやや大人しめで Linking 自体も本格的な普及はこれからのようですが、手元では BLE の勉強がてらにこの可愛いデバイスを楽しんでいます。
Pochiru
Braveridge 社はその後も活発に Linking 対応製品をリリースしています。最近目にとまった「Pochiru」というデバイスを買ってみました。Pochiru には LED に加えネーミングどおり押しボタンが実装されています。そのため通信先の機器との双方向のやりとりが可能です。
linkingiot.com
プログラムを書く
Tomoru や Pochiru のような Linking 対応デバイス用のアプリは Project Linking が無償で公開している SDK を利用して作成します。BLE まわりのハンドリングはすべて Linking 本体が仲介するため、抽象化された Linking API を呼び出すだけでデバイスとの連携が可能です。
Project Linking の開発者向けページの中ほどの「API guide」項の利用規約を確認の上 SDK をダウンロードし、「API 仕様書」の「ポーティング」ページの説明に添って開発環境をセットアップします。後は「API 仕様書」と SDK アーカイブに含まれる「LinkingIFDemo」のコードを読み合わせれば要領を理解しやすいでしょう。
手元では Android 版 SDK を利用しています。上記のサンプルを元に作成した簡単なアプリのコードを以下に示します。アプリの「LED」ボタンを押すと連携ずみデバイスの LED が点灯し、連携ずみデバイス側のボタン押下等のイベントによってアプリが通知を受けるとその旨を画面に表示する内容です。
試作：Linking01
MainActivity.java
/**
*
* Linking01
*
* - 連携ずみ Linking デバイスの LED を点灯させる
* - Linking デバイスからの通知を受け取る
*
*/
package jp.klab.Linking01;
import android.content.Context;
import android.content.SharedPreferences;
import android.media.AudioManager;
import android.media.ToneGenerator;
import android.os.Bundle;
import android.support.v7.app.AppCompatActivity;
import android.support.v7.widget.Toolbar;
import android.view.View;
import android.widget.Button;
import android.widget.Toast;
import com.nttdocomo.android.sdaiflib.Define;
import com.nttdocomo.android.sdaiflib.NotifyNotification;
import com.nttdocomo.android.sdaiflib.SendOther;
public class MainActivity extends AppCompatActivity
implements View.OnClickListener {
private Context mCtx;
private Button mButtonLED;
private static final byte LINKING_IF_PATTERN_ID = 0x20; //LEDパターンの設定項目ID（固定値）
private static final byte LINKING_IF_COLOR_ID = 0x30; //LED色の設定項目ID（固定値）
private static final byte COLOR_ID_RED = 0x01; // 点灯色
private static final byte BLINK_PATTERN = 0x22; // 点灯パターン
private NotifyNotification mNotifyNotification;
private MyNotificationInterface mMyNotificationInterface;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
mCtx = this;
setContentView(R.layout.activity_main);
Toolbar toolbar = (Toolbar) findViewById(R.id.toolbar);
setSupportActionBar(toolbar);
mButtonLED = (Button)findViewById(R.id.buttonLED);
mButtonLED.setOnClickListener(this);
// Linking デバイスからの通知受信用
mMyNotificationInterface = new MyNotificationInterface();
mNotifyNotification = new NotifyNotification(this, mMyNotificationInterface);
}
@Override
public void onClick(View v) {
// LED ボタン押下で連携ずみデバイスあてに LED 点灯指示を送る
if (v == (View)mButtonLED) {
SendOther sendOther = new SendOther(this);
sendOther.setIllumination(
new byte[] {
LINKING_IF_PATTERN_ID,
BLINK_PATTERN,
LINKING_IF_COLOR_ID,
COLOR_ID_RED
});
sendOther.send();
}
}
@Override
protected void onDestroy() {
super.onDestroy();
mNotifyNotification.release();
}
private class MyNotificationInterface implements NotifyNotification.NotificationInterface {
@Override
public void onNotify() { // 通知を受信した
// Linking デバイスからの通知内容は SharedPreferences に記録される
SharedPreferences preference =
getSharedPreferences(Define.NotificationInfo, Context.MODE_PRIVATE);
int DEVICE_ID = preference.getInt("DEVICE_ID", -1);
int DEVICE_BUTTON_ID = preference.getInt("DEVICE_BUTTON_ID", -1);
// Toast 表示
Toast.makeText(mCtx, "onNotify: DEVICE_ID=" + DEVICE_ID +
" DEVICE_BUTTON_ID=" + DEVICE_BUTTON_ID, Toast.LENGTH_SHORT).show();
// 音も鳴らす
ToneGenerator toneGenerator
= new ToneGenerator(AudioManager.STREAM_SYSTEM, ToneGenerator.MAX_VOLUME);
toneGenerator.startTone(ToneGenerator.TONE_CDMA_CALL_SIGNAL_ISDN_PING_RING);
}
}
}
試作の動作の様子
Linking でのデバイス・アプリの設定手順
Linking 対応デバイスと Linking アプリを連携させるためには事前に設定が必要です。手順は以下の要領です。
- 端末に「Linking」をインストールする（未インストールの場合のみ）
Linking（Android 版）- play.google.com
- 連携させるアプリ（ここでは自作の「Linking01」）のインストールを行い Linking を実行する
- 「デバイスの検索」を行い連携対象のデバイスを Linking に接続する（当該デバイスを未登録の場合のみ）
- デバイスの登録・接続が完了したら「デバイス詳細画面」へ移動し当該デバイスと連携させるアプリケーション（複数可。ここでは「Linking01」）を設定する
-
Linking を抜け上の手順で設定したアプリを起動してデバイスとの連携を確認する
備考： デバイスの Linking への再接続について
手元の Android 5.1 端末の環境では以下の現象が見られます。Linking のバージョンは 2016年8月現在最新の「03.10.00000」です。
- Linking に接続ずみのデバイスを Linking 上で「切断」すると再接続できなくなる
- Android の Bluetooth 設定において当該デバイスとのペアを解除してから Linking 上で再接続を行う
- Tomoruの接続トラブルシューティング (PDF) - www.products.braveridge.com
(tanabe)
MySQL プロトコル上のテキストの闇
MySQL 5.7 で JSON 型が追加されたのに関連して、私がメンテナをしている MySQL ドライバーで罠にハマったので、 MySQL のテキストプロトコルの闇を書き残しておくことにします。
Text Resultset
MySQL にクエリを投げるコマンドが COM_QUERY で、そのレスポンスとして返されるのが Text Resultset と呼ばれる一連のパケットです。その中身は次のようになっています。
- column count (整数1つだけのパケット)
- column definition * column count (各カラムの定義)
- EOF
- row * N (結果行数分)
- EOF
この記事で注目するのは column definition パケット (定義) の中にある、 column_type と character set です。
Python の MySQL ドライバーは、この2つの値を元に、 row に含まれる各バイト列を Python の適切な型の値に変換しています。
なお、以降に書く MySQL の振る舞いは、 MySQL 5.7.13 に基いています。
Character Set の闇
Q. connection encoding が latin1 のコネクションで、UTF-8 の VARCHAR 型のカラムに保存された「こんにちは」を SELECT したとき、 column definition の charset と row に含まれるバイト列はどうなるでしょう？
- charset=utf8, row には UTF-8 のバイト列
- charset=latin1, row には latin1で "?????"
A. 2
どうやら、 Column Definition にある character set は Column Character Set と無関係に connection encoding になるようです。 カラム毎に変わらないなら、なんで Column Definition に character set 書いてるんでしょうね?
あと、カラムの値は、カラムのエンコーディングからコネクションのエンコーディングにサーバーサイドで変換されるようです。 テキストの関数を使う必要が無いのなら、 VARCHAR や TEXT より VARBINARY や BLOB 使ったほうがエンコーディングに関わる問題を踏みにくそうです。
TEXT 型の闇
column type の一覧 を見てみると、 VARCHAR, VAR_STRING, STRING,
TINY_BLOB, MEDIUM_BLOB, LONG_BLOB, BLOB といった型があるのですが、 TEXT 型がありません。
Q. TEXT 型のカラムを SELECT したとき、 column definition の column_type は何になるでしょうか？
- VARCHAR
- STRING
- BLOB
A. 3
どうやら、 column_type は特にテキストとバイナリの区別を付けていないようですね。 区別付けないのはいいとして、型の名前として VARBINARY じゃなくて VARCHAR を使っているのに、 TEXT じゃなくて BLOB を使ってるのはどうなんでしょうか？テキストかバイナリのどちらかに寄せておいたほうが混乱が少ないと思うのですが。
さて、 Python ではテキストとバイナリを明確に区別したいです。 Java や C# もきっと同じだと思います。 その場合、 character set を見てテキストとバイナリを区別することができます。 character set が connection encoding と同じならテキストで、 binary ならバイナリです。
なお、 INT 型などは charset は binary が設定されます。 例えば 42 は ASCII の "42" として返ってくるので、文字列を10進整数としてパースしたい場合はいったん ASCII でデコードしてからパースすることになると思います。 これを擬似コードで書くとこうなります。
if column_type in [VARCHAR, VAR_STRING, ... 全ての文字列/バイナリ型]:
if charset == CHARSET_BINARY:
# バイト列
return data
else:
return data.decode(connection_encoding)
else: # 文字列以外
data = data.decode('ascii') # ascii でデコードしておいて、
return converters[column_type](data) # column_type ごとに用意した変換関数で変換する
JSON 型の闇
column_type には JSON が追加されました。そして MySQL 内部では JSON は常に UTF-8 (utf8mb4) で扱っているはずです。
さて、 column definition の character set はどうなっているでしょうか？
Q. connection encoding が utf8 のコネクションで、JSON 型のカラムを SELECT したとき、 character set は？
- binary
- utf8
- utf8mb4
A. 1
きっとテキスト型とちがって、カラムに character set を保存して無いので、文字列／バイナリ型以外の整数型などと同じように binary を返してしまうんでしょうね。
Q. connection encoding が utf8 のコネクションで、 SELECT CAST('{"hello": "world"}' AS JSON) AS anon_1 したとき、 character set は？
- binary
- utf8
- utf8mb4
A. 2
カラムと違ってコネクションには character set があるので、 それを返しているんでしょうね。でも、整数型とかは SELECT 42 しても binary なんですよね…
さて、上に書いた擬似コードを見て、JSON型のカラムをテキストとして返すにはどうすればいいか考えてみましょう。
結論: プロトコルを考えるときは、受け取る側がシステマチックに 解釈できるように(個別のif文が少なくなるように)設計しましょうね！！@methane
vmprof-flamegraph を作りました
vmprof-flamegraph を作ったのでその紹介をしておきます。
まず、サンプルとして Sphinx を使って Python のドキュメントをビルドしたときの vmprof 結果を flamegraph にしてみたので、どんなものかはこちらを見てみてください。
http://dsas.blog.klab.org/img_up/sphinx-prof.svg
flamegraph について
flamegraph の一般的な紹介については省略して、リンクだけ置いておきます。
公式サイト: http://www.brendangregg.com/FlameGraphs/cpuflamegraphs.html
日本語の紹介記事: http://d.hatena.ne.jp/yohei-a/20150706/1436208007
他にプロファイル結果をビジュアライズするツールとしては cachegrind 系 (kcachegrind, wincachegrind など) がありますが、 flamegraph の方がスタックトレースで 遅い部分が分かりやすいので最近のお気に入りです。
たとえばWebアプリで、ORMのクエリオブジェクトから実際のクエリを生成してそれを実行して結果をインスタンス化する処理が重い事がわかったとします。 その場合、 cachegrind 系でもどこから呼び出されているのが重いのかまではだいたい分かります。しかし flamegraph を使った場合は、 ここから呼び出された場合はインスタンス生成が重い（大量にオブジェクトを取得しているなど）、こっちから呼び出された場合はクエリビルドが重い （単純にクエリの実行回数が多いなど）、までひと目で把握することができます。
他のメリットとして、GUIアプリが不要でブラウザで見ることができるとか、 flamegraph.pl に食わせるデータファイルのテキスト形式が
grep などのツールと親和性が高い (興味がある関数で grep してから食わせることができる) などのメリットがあり、使いやすいです。
このテキストファイルのフォーマットはシンプルで、各行が次のようになっています。
トップレベルの関数名;1段深い関数名;一番深い関数名 サンプル数
関数名としているところは実際にはなんでも良く、サンプル数も整数であれば何でも良いです。なのでCPU時間以外にもメモリ使用量とかいろんな目的で利用することができます。
vmprof について
PyPy プロジェクトで開発されている、 PyPy と CPython 用のサンプリングプロファイラです。
サンプリングプロファイラなので、サンプル間隔を長めにすればオーバーヘッドを小さくすることができ、本番環境で動かすことも可能です。
まだまだ開発中のプロジェクトですが、サンプリングプロファイラ好きなので積極的に使っています。
vmprof はビジュアライザとして独自の Web アプリを開発していて、実際に http://vmprof.com/ で動いています。 特に PyPy のプロファイル結果を見る場合、 JIT のウォームアップなども見ることができます。
この Web アプリは https://github.com/vmprof/vmprof-server を見れば（ある程度のPythonの知識があれば）簡単に動かすことができます。
vmprof-flamegraph について
簡単に動かせると言っても、プロファイル結果を見るためだけに社内でWebアプリを運用するのも面倒です。 CPython で動かしているアプリのプロファイルを見るだけなら flamegraph を使うほうがお手軽です。
ということで、 vmprof が生成するバイナリ形式のプロファイル結果を、 flamegraph.pl の入力フォーマットのテキストファイルに変換するのが vmprof-flamegraph になります。
インストール方法は、 flamegraph.pl を PATH が通ったディレクトリに置いておき、 vmprof をインストールした Python の環境で
pip install vmprof-flamegraph するだけです。
その Python 環境の bin ディレクトリに vmprof-flamegraph.py がインストールされます。
使い方は次のような感じになります。
$ python3 -m vmprof -o profile.data <Pythonスクリプト> $ vmprof-flamegraph.py profile.data | flamegraph.pl > profile.svg $ open profile.svg # Mac の場合
詳細は vmprof-flamegraph や flamegraph.pl のヘルプを見てください。
@methane
Python に現在実装中の Compact dict の紹介
背景
2015年1月に、 PyPy の開発者Blogにこんな記事がポストされました。
Faster, more memory efficient and more ordered dictionaries on PyPy
その後リリースされた PyPy 2.5.1 から dict は挿入順を維持するようになり、メモリ使用量も削減されました。
一方 CPython では、 PEP 468 で、キーワード引数を **kwargs という形式の仮引数で受け取るときに、引数の順序を保存しようという提案がされました。
例えば、 SQLAlchemy のクエリーで .filter_by(name="methane", age=32) と書いたときに生成されるクエリーが WHERE name = "methane" AND age = 32 になるか WHERE age = 32 AND name="methane" になるか不定だったのが、ちゃんと順序を維持するようになるといったメリットがあります。
(filter_by は等式専用のショートカット関数であって、キーワード引数を使わない filter というメソッドを使えば順序も維持されます。)
この提案者は pure Python だった OrderedDict クラスをCで再実装して、 Python 3.5 から OrderedDict がより高速かつ省メモリになりました。 (dict の方の修正を避けたのは、それだけ dict が Python インタプリタのために複雑に最適化されているからです。)
しかし、Cで再実装されたとは言え、双方向リンクリストで順序を管理された OrderedDict はそれなりにオーバーヘッドがあります。特にメモリ使用量については、倍近い差があります。
Python 3.5.1 (default, Dec 7 2015, 17:23:22)
[GCC 4.2.1 Compatible Apple LLVM 7.0.0 (clang-700.1.76)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> d = {i:i for i in range(100)}
>>> from collections import OrderedDict
>>> od = OrderedDict((i,i) for i in range(100))
>>> sys.getsizeof(d), sys.getsizeof(od)
(6240, 11816)
そのせいもあり、まだ PEP 468 は止まったままになっています。
私も、一部のユースケースで便利だからといって、全てのキーワード引数の性能を落とす可能性がある変更には抵抗があり、また PyPy の実装した dict に興味があったので、 Python 3.6 にギリギリ間に合う今のうちに挑戦することにしました。
(予定では9月前半に beta リリースされ機能追加できなくなるので、それまでに実装、評価検証、MLでの議論などを経てマージされる必要があります)
データ構造
変更した構造体は PyDictKeysObject だけです。ただし、以前よりメモリレイアウトがより動的になります。
struct _dictkeysobject {
Py_ssize_t dk_refcnt;
Py_ssize_t dk_size;
dict_lookup_func dk_lookup;
Py_ssize_t dk_usable;
Py_ssize_t dk_nentries; /* How many entries is used. */
char dk_indices[8]; /* dynamically sized. 8 is minimum. */
};
#define DK_SIZE(dk) ((dk)->dk_size)
#define DK_IXSIZE(dk) (DK_SIZE(dk) <= 0xff ? 1 : DK_SIZE(dk) <= 0xffff ? 2 : \
DK_SIZE(dk) <= 0xffffffff ? 4 : sizeof(Py_ssize_t))
#define DK_ENTRIES(dk) ((PyDictKeyEntry*)(&(dk)->dk_indices[DK_SIZE(dk) * \
DK_IXSIZE(dk)]))
dk_get_index(PyDictKeysObject *keys, Py_ssize_t i)
{
Py_ssize_t s = DK_SIZE(keys);
if (s <= 0xff) {
return ((char*) &keys->dk_indices[0])[i];
}
else if (s <= 0xffff) {
return ((PY_INT16_T*)&keys->dk_indices[0])[i];
}
else if (s <= 0xffffffff) {
return ((PY_INT32_T*)&keys->dk_indices[0])[i];
}
else {
return ((Py_ssize_t*)&keys->dk_indices[0])[i];
}
}
dk_set_index(PyDictKeysObject *keys, Py_ssize_t i)
{
...
以前のハッシュテーブルは 3word (hash, key, value) の PyDictKeyEntry 構造体の配列でしたが、こちらの方式ではハッシュテーブルの要素をただの整数型にしています。
構造体の宣言では char dk_index[8] になっていますが、これは最小の dk_size が8の時の大きさで、実際にはアロケート時により大きいサイズを確保します。さらに、この整数型自体も dk_size が 128 までは char ですが 256 からは int16_t になります。このようにしてギリギリまでハッシュテーブルのサイズを小さくします。
さらに、 dk_indices のサイズが動的なので構造体に直接宣言できませんが、この構造体の後ろに PyDictKeyEntry 構造体の配列を置いています。この配列のサイズは dk_size ではなくその 2/3 (前回の記事で紹介した、このハッシュテーブルに挿入可能な最大要素数) にしています。新しい要素を挿入するときは、この配列に追記していき、そのインデックスを dk_indices に保存します。 dk_nentries は配列中の要素数になります。
挿入時の操作を、同じキーがまだ存在しないと仮定した擬似コードで示すとこうなります。
// dk_indices 内の挿入位置を検索 pos = lookup(keys, key, hash); // エントリ配列にエントリを追記する DK_ENTRIES(mp)[keys->dk_nentries].me_hash = hash; DK_ENTRIES(mp)[keys->dk_nentries].me_key = key; DK_ENTRIES(mp)[keys->dk_nentries].me_value = value; // dk_indices にそのエントリのインデックスを保存 dk_set_index(keys, pos, keys->dk_nentries); // 最後に使用済みエントリ数をインクリメント mp->dk_nentries++;
削除
この dict からアイテムを削除するには、 dk_indices の該当位置にダミー要素を代入しておきます。 (各インデックスが1バイトで扱えるエントリー数が256までではなく128までなのは、マイナスの値をダミーと空を表すために利用しているからです。)
エントリーからの削除については2つの方式があります。
最初に compact dict のアイデアが Python の開発者MLに投稿されたときは、最後の要素を削除された要素があった位置に移動することで、エントリー配列を密に保っていました。この方式では最後の要素が前に来るので、「挿入順を保存する」という特性が要素を削除したときに失われます。
一方、 PyPy や今回僕が採用したのは、単に空いた場所に NULL を入れておくというものです。
// dk_indices 内の削除する要素のインデックスがある位置を検索 pos = lookup(keys, key, hash); // 削除する要素のエントリー配列内の位置を取得する index = dk_get_index(keys, pos); // 要素を削除する DK_ENTRIES(mp)[index].me_key = NULL; DK_ENTRIES(mp)[index].me_value = NULL; // dk_indices にダミーを登録 dk_set_index(keys, pos, DUMMY);
こちらの方式は、挿入と削除を繰り返したときにエントリー配列がダミーでいっぱいになってコンパクションを実行する必要があるというデメリットがあります。 しかし、実は最初に提案された方式でも、挿入と削除を繰り返すうちにハッシュテーブルがダミーで埋まってしまい検索ができなくなってしまう可能性があるので、どちらにしろコンパクションは必要になります。そのため、挿入順を維持する方が良いと判断しました。
ちなみに、 .popitem() は、エントリー配列のうち最後の要素を削除し、 dk_nentries をデクリメントすることで、平均計算量を O(1) に保っています。
この場合も dk_usable という「残り挿入可能数」をインクリメントしないので、削除と挿入を繰り返すとコンパクションを実行してハッシュテーブルを再構成します。
Shared-Key dict
さて、問題の shared key dict です。
最初は、 compact dict を実装する前と同じように、ハッシュテーブルにダミー要素を挿入せず、エントリー配列側が NULL になっていたらダミーと判断すれば良いと思っていました。
しかし、これでは shared key に最初に要素を追加した dict の挿入順しか保存することができません。
>>> class A:
... pass
...
>>> a = A()
>>> b = A()
>>> a.a = 1
>>> a.b = 2
>>> b.b = 1
>>> b.a = 2
>>> a.__dict__.items()
dict_items([('a', 1), ('b', 2)])
>>> b.__dict__.items() # 挿入順は b, a なのに、、、
dict_items([('a', 2), ('b', 1)])
この問題について、次の3つの方針を考えていますが、MLで議論した上でGuidoかGuidoが委任したコア開発者が最終決定するまでどれになるか分かりません。
(1) ありのままを受け入れる
今の Python の言語仕様では、 dict の順序は不定です。なので、「インスタンスの属性を管理する dict を除いて挿入順を保存する」という今の動作も、言語仕様的には問題ないことになります。
compact dict になると shared key dict も ma_values 配列のサイズが dk_keys からその 2/3 になってよりコンパクトになるので、その恩恵を完全に受ける事ができます。
一方、デメリットとしては、殆どのケースで挿入順を保存するように振る舞うので、言語仕様を確認しない人はそれが仕様だと誤解してしまうことがあります。 この問題は「誤解するほうが悪い」とするのは不親切です。 たとえば Go はこのデメリットを避けるために、 map をイテレートするときの順序を意図的に (高速な擬似乱数を使って) 不定にしています。
(2) 挿入順が違ったら shared key をやめる
shared key が持っている順序と違う順序で挿入されようとしたらすぐに shared key をやめるという方法があります。
一番無難な方法に見えますが、どれくらい shared key を維持できるのかわかりにくくてリソース消費が予測しにくくなるとか、稀に通るパスで挿入順が通常と違い、 shared key が解除されてしまうと、同じサイズの dict を同じくらい利用し続けてるのにメモリ使用量がじわじわ増えてくる、といった問題があります。
実行時間が長い Web アプリケーションなどのプログラムで、メモリ消費量が予測しづらく、じわじわ増えるのは、あまりうれしくありません。 なので私はこの方式に乗り気では無いです。
(3) Shared Key Dict をやめる
shared key dict は、ハマったときはとても効率がいいものの、 compact ordered dict の方が安定して効率がいいです。 しかも shared key dict をサポートするために、 dict の実装がだいぶ複雑になってしまっています。
実際に shared key dict を実装から削ってみた所、4100行中500行くらいを削除することができました。簡単に削除しただけなので、さらにリファクタリングして削れると思います。
一方効率は、 Python のドキュメントを Sphinx でビルドするときの maxrss を /usr/bin/time で計測した所、
- shared: 176312k
- compact + shared: 158104k
- compact only: 166888k
という感じで、 shared key をやめても compact dict の効果によるメモリ削減の方が大きいという結果がでました。
（もちろんこれは1つのアプリケーションにおける結果でしか無いので、他に計測に適した、クラスやインスタンスをそこそこ使って実行時間とメモリ使用量が安定している現実のアプリケーションがあれば教えてください。）
また、 shared key を削除して実装を削れた分、別の効率のいい特殊化 dict を実装して、 compact + shared よりも高い効率を狙うこともできます。 今はあるアイデアのPOCを実装中なので、採用されたらまた紹介します。
OrderedDict
OrderedDict を compact dict を使って高速化する方法についても補足しておきます。
Python 3 には、 Python 2.7 には無かった move_to_end(key, last=True) というメソッドがあります。このキーワード引数がクセモノで、 move_to_end(key, last=False) とすると先頭に移動することができます。（機能はともかくメソッドの命名についてはとてもセンスが悪いと思います。 move_to_front(key) でええやん。）
この機能を実装するために、 dk_entries 配列をキャパシティ固定の動的配列ではなく、キャパシチィ固定の deque として扱うというアイデアを持っています。 つまり、今は dk_entries[0] から dk_entries[dk_nentries-1] までを使っているのですが、それに加えて先頭に要素を追加するときは dk_entries の後ろから先頭に向かって挿入していきます。
これを実現するには dk_nentries の反対版を作って、ハッシューテーブルの走査やリサイズがその部分を扱うように改造すれば良いです。 OrderedDict 1つあたり 1word (8byte) を追加するだけで、消費メモリを半減させることが可能なはずです。
ですが、Shared-Key 問題で手一杯なうえ、 dict が挿入順を保存するようになったら OrderedDict の利用機会も減ってしまうので、このアイデアを実装するモチベーションがありません。少なくとも Python 3.6 には（誰かが僕の代わりに実装してくれない限り）間に合わないでしょう。
@methane
![BLUETOOTH SPECIFICATION Version 4.2 [Vol 3, Part B] page 227](http://livedoor.blogimg.jp/klab_gijutsu2/imgs/b/8/b8ada218.png){kind=link}
