[過去ﾛｸﾞ]
【通知来ない】Doze総合【GCM？】©2ch.net (507ﾚｽ)
【通知来ない】Doze総合【GCM？】©2ch.net http://egg.5ch.net/test/read.cgi/smartphone/1481986840/
上
下
前
次
1-
新
通常表示
512ﾊﾞｲﾄ分割
ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索
歴削→次ｽﾚ
栞削→次ｽﾚ
過去ﾛｸﾞﾒﾆｭｰ
184: SIM無しさん [sage] 2016/12/30(金) 18:41:16.65 ID:Xq2a/kM3 ↑ ごめん違う Disabledoze はDozeに入った直後に止めている。 http://egg.5ch.net/test/read.cgi/smartphone/1481986840/184
185: SIM無しさん [sage] 2016/12/31(土) 16:11:27.53 ID:a+zP8RTj >>180 うろ覚えだがGmailはsession保持がたしか20分くらいだったような 無通信（keep aliveなし）でも相手が同じIPでListeningしていると見なす時間が長ければ長いほどクライアントには都合がいいが、鯖にとってはいい迷惑なのでGmailがフリーでは最大級なんだろうな（憶測） Gmailでもダメな人は自前で鯖を立てる Exchangeはデフォ30分最大一日とかできたはず…アホくさコスト的にありえん http://egg.5ch.net/test/read.cgi/smartphone/1481986840/185
186: SIM無しさん [sage] 2016/12/31(土) 16:12:05.78 ID:a+zP8RTj >>185 また、鯖からkeep aliveを投げてもらっての応答ではDoze回避できないと思われるので、むしろ鯖からkeep aliveはない方がよさそう （応答無しで切断と見なされ、session破棄されそう） あとはクライアント側がDozeでもkeep aliveするようにsetAlarmClock()で短時間で起きるか（たしか時計アイコンが強制表示される） そんなことしたらStoreから蹴られるだろうな http://egg.5ch.net/test/read.cgi/smartphone/1481986840/186
187: SIM無しさん [sage] 2016/12/31(土) 16:12:45.10 ID:a+zP8RTj >>186 k-9使ってる人はグローバル設定-ネットワーク-バックグラウンド同期-常時利用にしてみてる？ まあk-9はIMAP idleではその設定が必須だからトラブってる人はいないか… http://egg.5ch.net/test/read.cgi/smartphone/1481986840/187
188: SIM無しさん [sage] 2017/01/01(日) 14:01:21.25 ID:+UjFEPBG >>177 同期を15分にしたらどうだろうか。 http://egg.5ch.net/test/read.cgi/smartphone/1481986840/188
189: SIM無しさん [sage] 2017/01/02(月) 01:21:25.12 ID:gMoxHbFE Disable Dozeって7.0でも使えてる？ アップデートしようか迷ってる。せっかくこれのお陰でメール問題解決したから、7.0で使えないなら上げたくないな。 http://egg.5ch.net/test/read.cgi/smartphone/1481986840/189
190: SIM無しさん [sage] 2017/01/02(月) 03:36:56.27 ID:yqp3XJt7 Gmailの通知が来ない状態ではどういう問題が起きているのか LAN内のルータマシンにWiresharkを入れてアクアとimap.gmail.comとの間の通信を キャプチャして調べようと思ったけど なぜかDoze中も通知が来なくならない ありがたいけどこれじゃ調べられない 通信がSSL(TSLv1.2)だから暗号化されていて完全には分からないけど 待ち状態になった後にアクア側からパケットが送られる場合(多分LOGOUT)も Gmail側からパケットが送られる場合(多分タイムアウト)も アクアは必ず「IMAPプッシュセッションの持続時間」ごとに新しいTCP接続を作っている これだと通知が来なくならない キャプチャしてみてGmailは切断する時にいきなりぶった切ることが分かった (IMAPのレスポンスを送って来ずにいきなりTCP FINを送ってくる しかもそれに対してアクアがFINを返すとRSTを返してくる) それがアクアに必ず新しいTCP接続を作らせているのかもしれない アクア+Gmailの組み合わせの場合は もしかするとタイムアウトによる通知が来なくなる問題は起きないのかもね もしそうなら>>180の人も説明が付く http://egg.5ch.net/test/read.cgi/smartphone/1481986840/190
191: SIM無しさん [sage] 2017/01/03(火) 11:58:05.81 ID:wZPPMN5s Heartbeat Fixer for GCMを入れてポート5228をWiresharkで監視して GCMの動作を調べてみた Doze中のハートビートは Heartbeat Fixer for GCMで何分に設定してもOFFにしても変化がなく、 1740秒(29分)間隔で端末側からパケットが送られていた それに加えてメンテナンスウィンドウが来たらそのタイミングでもハートビートが送られた 上の方で、Heartbeat Fixer for GCMで通知が来るようになった後で アンインストールしても通知が来る状態が維持されているという話があったので 初回インストール前だと挙動が違うのかもしれないが 俺も入れてしまっていたのでそれは確認できていない これで解決する人の環境では 通信路のどこかに30分以上無通信だと回線切断される部分があって (WiFiとかNATとかモバイルネットワークとか) 何でもいいから29分に1回通信が起きれば接続が維持されて 通知が止まらなくなるのかもしれない あと公式TwitterアプリはDMはpriority : highでメンションはpriority : normalと分かっているのを 利用してpriorityごとの挙動も調べたら Doze中はnormalだと端末にパケットの送信すらされていなかった どうやってGCMサーバ側で端末がDoze中かどうかが分かるのか不明だが ハートビートで送信する35バイトのデータの中で状態通知しているのかもしれない GCMの生データは人間可読でないので中身は確認できていない http://egg.5ch.net/test/read.cgi/smartphone/1481986840/191
192: SIM無しさん [sage] 2017/01/03(火) 12:52:48.96 ID:xSbSEOU+ GCMを高にするオプション追加するとヘッダーに何か追加されるってデベロッパーサイトで見た気がしたけど 検索するの面倒だから気になる人は自分で探してくれｗ http://egg.5ch.net/test/read.cgi/smartphone/1481986840/192
193: SIM無しさん [sage] 2017/01/03(火) 13:19:27.58 ID:uRPKfbX2 http://mslgt.hatenablog.com/entry/2016/04/23/001000 http://egg.5ch.net/test/read.cgi/smartphone/1481986840/193
194: SIM無しさん [sage] 2017/01/03(火) 15:02:16.63 ID:gnOXts3O すまん長い >>191 なにもGCMでやりとりするものがなくても、GCM鯖から15分くらいに一回パケットこない？ ExchangeやIMAP-IDLEとネットワーク的にはやり口似てる keep aliveを15や30分毎にするけど、その間はsession繋がったままlisteningしていると仮定してるだけ sessionをやたら短時間で破棄される環境だと、GCMもIMAP-IDLE同様切られて通知出なくなる ネットワーク的にはExchange/IMAP-IDLE程度に脆弱 DozeでGCMが有利なのは、Google Play開発者サービスがシステムアプリの上、Doze除外されている常駐サービスのため 他アプリは定期的にkeep alive送りたいけどDozeで仮死になっちゃう Google Play開発者サービスはDoze関係なくkeep alive送れるので、たとえsession切れてても張り直しする > どうやってGCMサーバ側で端末がDoze中かどうかが分かるのか不明だが ttps://developers.google.com/cloud-messaging/server DozeったときにXMPPで送ってるのかもしれないけど、GCMドキュメントで見たことない実装なのでなんとも GCM鯖が端末状態を把握する必要はないと思うんだけどな http://egg.5ch.net/test/read.cgi/smartphone/1481986840/194
195: SIM無しさん [sage] 2017/01/03(火) 23:29:49.21 ID:wZPPMN5s >>194 1740秒の間には特にパケット来なかったよ Wiresharkのポート5228のキャプチャはこんな感じ (デフォルト出力から、2カラム目にtcp.stream、3カラム目にtcp.time_deltaを追加して 長文規制対策でInfoの後半を消してある) 4738 5 1740.864185000 2017-01-03 05:22:44.71 mobile mobile-gtalk.l.google.com TCP 101 55335→5228 4739 5 0.039409000 2017-01-03 05:22:44.75 mobile-gtalk.l.google.com mobile TCP 99 5228→55335 4740 5 0.004986000 2017-01-03 05:22:44.75 mobile mobile-gtalk.l.google.com TCP 66 55335→5228 4800 5 1741.944733000 2017-01-03 05:51:46.70 mobile mobile-gtalk.l.google.com TCP 101 55335→5228 4801 5 0.038764000 2017-01-03 05:51:46.74 mobile-gtalk.l.google.com mobile TCP 99 5228→55335 4802 5 0.004708000 2017-01-03 05:51:46.74 mobile mobile-gtalk.l.google.com TCP 66 55335→5228 5089 5 1740.916525000 2017-01-03 06:20:47.66 mobile mobile-gtalk.l.google.com TCP 101 55335→5228 5090 5 0.038665000 2017-01-03 06:20:47.70 mobile-gtalk.l.google.com mobile TCP 99 5228→55335 5091 5 0.003172000 2017-01-03 06:20:47.70 mobile mobile-gtalk.l.google.com TCP 66 55335→5228 てっきりpriority : normalのメッセージも端末に送信はされていて Google Play開発者サービスが保留しておくのだと思ってたけど 以下のようにメンションのメッセージがそもそも送信されてこなくて意外だった 9788 5 1740.938847000 2017-01-03 11:28:03.59 mobile mobile-gtalk.l.google.com TCP 101 55335→5228 9789 5 0.037525000 2017-01-03 11:28:03.63 mobile-gtalk.l.google.com mobile TCP 99 5228→55335 9790 5 0.006878000 2017-01-03 11:28:03.64 mobile mobile-gtalk.l.google.com TCP 66 55335→5228 ここでメンションを送るがしばらく待ってもパケットは来ない 11:33:32にDMを送る 9819 5 328.677322000 2017-01-03 11:33:32.32 mobile-gtalk.l.google.com mobile TCP 129 5228→55335 1秒以内にメッセージが来た 9820 5 0.000278000 2017-01-03 11:33:32.32 mobile-gtalk.l.google.com mobile TCP 161 5228→55335 9821 5 0.000009000 2017-01-03 11:33:32.32 mobile-gtalk.l.google.com mobile TCP 225 5228→55335 9822 5 0.000007000 2017-01-03 11:33:32.32 mobile-gtalk.l.google.com mobile TCP 867 5228→55335 9823 5 0.000005000 2017-01-03 11:33:32.32 mobile-gtalk.l.google.com mobile TCP 460 5228→55335 9824 5 0.083183000 2017-01-03 11:33:32.40 mobile-gtalk.l.google.com mobile TCP 460 TSecr=418168 9825 5 0.102833000 2017-01-03 11:33:32.50 mobile mobile-gtalk.l.google.com TCP 66 55335→5228 9826 5 0.000001000 2017-01-03 11:33:32.50 mobile mobile-gtalk.l.google.com TCP 66 55335→5228 9827 5 0.000000000 2017-01-03 11:33:32.50 mobile mobile-gtalk.l.google.com TCP 66 55335→5228 9828 5 0.000000000 2017-01-03 11:33:32.50 mobile mobile-gtalk.l.google.com TCP 66 55335→5228 9829 5 0.001457000 2017-01-03 11:33:32.50 mobile mobile-gtalk.l.google.com TCP 66 55335→5228 ここまでがDMの内容を受信するメッセージだと思われる 30秒待っても追加のメッセージが来ないので画面を点灯してDozeを抜けた 画面を点灯した瞬間はDMの通知しか表示されていなかった 9942 5 35.539739000 2017-01-03 11:34:08.04 mobile mobile-gtalk.l.google.com TCP 168 55335→5228 この時点でメンションの内容を受信するメッセージと思われるものが来た 9943 5 0.039229000 2017-01-03 11:34:08.08 mobile-gtalk.l.google.com mobile TCP 1121 5228→55335 9944 5 0.000014000 2017-01-03 11:34:08.08 mobile-gtalk.l.google.com mobile TCP 432 5228→55335 9945 5 0.006571000 2017-01-03 11:34:08.09 mobile mobile-gtalk.l.google.com TCP 66 55335→5228 9946 5 0.000001000 2017-01-03 11:34:08.09 mobile mobile-gtalk.l.google.com TCP 66 55335→5228 11094 5 21.203318000 2017-01-03 11:34:29.29 mobile mobile-gtalk.l.google.com TCP 168 55335→5228 11095 5 0.076582000 2017-01-03 11:34:29.37 mobile-gtalk.l.google.com mobile TCP 66 5228→55335 http://egg.5ch.net/test/read.cgi/smartphone/1481986840/195
196: SIM無しさん [sage] 2017/01/05(木) 14:24:57.44 ID:g/T7zjzy >>195 > 1740秒の間には特にパケット来なかったよ ドキュメントと違いすぎる…。 NATなどでsessionが実は切れててとかではと思ったけど。 > 4740 5 0.004986000 2017-01-03 05:22:44.75 mobile mobile-gtalk.l.google.com TCP 66 55335→5228 > 4800 5 1741.944733000 2017-01-03 05:51:46.70 mobile mobile-gtalk.l.google.com TCP 101 55335→5228 ログ見ると約30分後端末からパケット何事もなく流れてるし…。 端末からkeep aliveしてその応答する以外は、GCMなにも手当してくれていないように見えるなあ。 経路理由でsession切れてたらGCMでも最大約30分無通知か。 この面はキャリアメール（SMSトリガー）しか信用ならないのが全く崩れないなあ。 > てっきり 同意。 せいぜいDisableDozeなり、adbなり、rootなりして、バッテリー捨てていくしかないわけですな。 バッテリー捨てるならGCM要らない子じゃねえか…。 参考サイト ttp://blog.livedoor.jp/gnunobian/archives/52030755.html ttp://dsas.blog.klab.org/archives/52074007.html ttp://risurisu.seesaa.net/s/article/380643899.html ttp://creamsnexus.blogspot.jp/2013_10_01_archive.html 公式が役に立たねえ…。 http://egg.5ch.net/test/read.cgi/smartphone/1481986840/196
197: SIM無しさん [] 2017/01/05(木) 14:56:33.00 ID:AuL6q3Ox こんなのだとGCM優先度高でも通知遅れるわけだ http://egg.5ch.net/test/read.cgi/smartphone/1481986840/197
198: SIM無しさん [sage] 2017/01/05(木) 15:14:43.04 ID:iLM3aIhu >>196 Doze以前のGCMの実測調査は全部アテにならないってことだね・・・ http://egg.5ch.net/test/read.cgi/smartphone/1481986840/198
199: SIM無しさん [sage] 2017/01/06(金) 23:56:22.80 ID:Jy2IYSCA >>198 そこまでは言わない。 広範に複数環境での検証報告出てこないとなんとも。 ただ現実に互いに約30分無通信ログを見てしまうと、こりゃGCM高がベストプラクティスなんてとても言えん。 通話やSMSに大きく（最大約30分）劣る信頼性しかないことを、改めて認識させられたところ。 http://egg.5ch.net/test/read.cgi/smartphone/1481986840/199
200: SIM無しさん [sage] 2017/01/06(金) 23:57:12.26 ID:Jy2IYSCA >>199 一方で、端末も鯖もsession張れていると勘違いしたまま経路断なんてそうそうあるかと言えばそんなにはない。 ただIPv4枯渇のおかげでNATだらけ。 おかげで切れやすいので、ローカルIP配布のISPはこの面で、実は隠れた形でリスク高しと言ったところかな。 （既出のttp://risurisu.seesaa.net/s/article/380643899.html参考） これはDozeやGCMの問題ではなく、ネットワークのしかもNAT timeout問題なので、Google的には知らん顔だろう。 http://egg.5ch.net/test/read.cgi/smartphone/1481986840/200
201: SIM無しさん [sage] 2017/01/06(金) 23:57:50.03 ID:Jy2IYSCA >>200 そこはいい。 ただDozeのオンオフはユーザーに（少なくとも当分は）選択肢があるべき。 Dozeさえかからなければ、バッテリー捨てながらアプリにkeep aliveさせりゃいいんだから。 それは単にL以前に戻るだけとも言える。 ただ現状、具体的対策がDisableDoze/adb/rootになってしまうのは…。 http://egg.5ch.net/test/read.cgi/smartphone/1481986840/201
202: SIM無しさん [sage] 2017/01/07(土) 00:15:20.44 ID:2CV1rina >>200 WiFi接続ならそうそう経路断は起きないと思うけど モバイルネットワークではよくあるよね MVNOの短時間タイムアウトのことはそのリンク先にも書いてあるけど キャリアでもいつの間にか外部IPアドレスが変わってることはよくある (2chのIDがころころ変わったりする)から その時には経路断になってるはず それでプッシュが来なくなってるんだと思う http://egg.5ch.net/test/read.cgi/smartphone/1481986840/202
203: SIM無しさん [sage] 2017/01/07(土) 03:50:50.13 ID:kd/qdF6m Yahooメールの「リアルタイムで受信（プッシュ）」設定での通信もWiresharkで調べてみた GCMとSSLの組み合わせだった SSL上のプロトコルは暗号化されて見えないので不明だけど ポートが443だからIMAPじゃなくてHTTPSのRESTか何かの可能性が高い メールが来るたびにTCP接続を作り直しているので少なくともIMAP IDLEではない あと俺の環境ではDoze中は通知が出なかった 優先度は通常なのか？ 以下キャプチャ 03:26にメールを送る。この時点ではDoze中 03:35にパケットが来ないので画面を点灯させてDozeを抜けた すぐに端末側からGCMのパケットを送信 6436 147 1444.191282000 2017-01-07 03:35:57.66 mobile mobile-gtalk.l.google.com TCP 166 47644→5228 [PSH, ACK] 6438 147 0.038035000 2017-01-07 03:35:57.69 mobile-gtalk.l.google.com mobile TCP 66 5228→47644 [ACK] GCMサーバ側からYahooメールの受信フラグと思われるメッセージが来る 6439 147 0.000721000 2017-01-07 03:35:57.69 mobile-gtalk.l.google.com mobile TCP 301 5228→47644 [PSH, ACK] 6440 147 0.002176000 2017-01-07 03:35:57.70 mobile mobile-gtalk.l.google.com TCP 66 47644→5228 [ACK] GCMを受けただけでは通知は出ない GCMの数秒〜1分後に端末側からlogql.g.yahoo.co.jp:443へ接続 通知はこの時点で出る 6656 170 0.000000000 2017-01-07 03:35:59.52 mobile logql.g.yahoo.co.jp TCP 74 48435→443 [SYN] 6659 170 0.007551000 2017-01-07 03:35:59.53 logql.g.yahoo.co.jp mobile TCP 74 443→48435 [SYN, ACK] 6661 170 0.002424000 2017-01-07 03:35:59.53 mobile logql.g.yahoo.co.jp TCP 66 48435→443 [ACK] 6662 170 0.003004000 2017-01-07 03:35:59.54 mobile logql.g.yahoo.co.jp TLSv1.2 262 Client Hello http://egg.5ch.net/test/read.cgi/smartphone/1481986840/203
上
下
前
次
1-
新
書
関
写
板
覧
索
設
栞
歴
あと 304 ﾚｽあります
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
AAｻﾑﾈｲﾙ
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.008s