yamk blog

2009年6月13日に、最初の Twitpocalypse が起こった。Twitter のメッセージ ID が、32bit 符号付き整数の 2,147,483,647 (21億 4748万 3687) を越えたため、Twitter API を使った一部のクライアントの挙動がおかしくなって、新しい TL(タイムライン) の読み込みや 検索、返信機能に障害が出た。ただし、Twitter サーバ側では既に 64bit符号なし整数に対応していたため、Web インターフェースでは問題は出なかった。

C でいうところの long int ではダメで、unsigned long long int にせよという対策が実施され、クライアント群がアップデートされて解決した。

さて、昨日まであまり話題にもなっていなかったので気づかなかったが、Twitpocarlypse II または Twitpocalypse Redux というタイトルで予告されていたようで、次の壁である 32bit符号なし整数の最大値：

4,294,967,295 (42億 9496万 7295) = 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111

をこの 9/22 に越えたらしい。

たったの3ヶ月で総メッセージが倍になるとは。21億つぶやきだよ。恐るべし Twitter の伸び率。

実はこのあたりが不明瞭なのだが、

Twitpocalypse―TwitterメッセージIDの64ビット化―いよいよ明日に実施
(TechCrunch JAPAN 2009/9/22)

を読むと、内部の 64ビット化を実施とある。あれ？ もうとっくに対応してたんじゃないの？ まだ unsigned long int の部分があったってこと？

とりあえず、手元の Tweetie, TweetDeck (Mac版) および Twitterific premium では問題なさそうだ。@iphonefan の TL を眺めていると、Twittelator Pro が今朝から不調らしい。これが原因かは不明。

参考：

Coming This September: Twitpocalypse Now Redux! (TechCrunch, 2009/7/31)

Twitpocalypse II Coming To A Twitter Client Near You This Friday
(TechCrunch, 2009/9/9)

Alert: “Twitpocalypse II” coming Friday, September 11th – make sure you can handle large status IDs! (Twitter Development Talk, 2009/9/10)

Twitpocalypse II Update – Scheduled for Tuesday 9/22 at 11:30am PST (Twitter Development Talk, 2009/9/22)

Twitpocalypse Redux is upon us! ※カウント中

Update: 各クライアントも細かく障害が出ていたようで、続々と対応バージョンがリリース。

昨晩書いた Twitpocalypse 問題。今朝 (6/13) 9:00 の段階では既に臨界点を越えていた。いろいろクライアントを試してみた。

Twitterrific 3.2 (Mac)

• 問題なし

Tweetie 1.2.2 (Mac)

• 1.2.2 リリース

TweetDeck  0.25.1 (Adobe AIR)

• 0.25.1 対応版リリース済

Twitterific Premium 2.0.1 (iPhone)

• 最新のタイムラインをダウンロードしようとすると、エラーが表示される
• 2.0.2 Apple 審査待ち (※無料版の Twitterrific は公開)

Tweetie 1.3.1 (iPhone)

• タイムラインは取得できる
• 検索とトレンドに問題？
• 対応バージョンは Apple 審査待ち

Twittelator Pro 2.3 (iPhone)

• 問題なし

Twitterfon 1.5.2 (iPhone)

• 問題なし

一番使っていたクライアントだけが使えなくなったのががっくり。

ついでに、いろいろ試していたら、Twitter の時間あたりの取得制限にひっかかって全く読めなくなった orz

Twitpocalypse (ツイットポカリプス) (yebo blog, 2009/6/12)

という記事が公開されている。なんでも Twitter メッセージの ID が 32bit 符号付き整数 (32bit signed int) で解釈された場合、この週末あたりで

2,147,483,647 (= 01111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111)

を越えて負の値になってしまうそうだ。 現在の ID をカウントするサイト

Twitpocalypse

が末期的雰囲気を醸し出している。一部では Twitter が崩壊するぐらいの勢いで噂されている。

‥‥が、どうもおかしい。本当に致命的な不具合だったら本家サイトで何らかの大がかりなアナウンスがあってもよいように思える。そこで、本当のところどうなのか少し調べてみた。

データが化けそうな（丸めや変換による劣化が起きそうな）ポイントとしては大きく3つに分けられる。

1. Twitter サイト側のデータベースおよびサーバ側の処理
2. Twitter サーバとクライアント間の送受信のデータフォーマット
3. Twitter クライアントの処理

このうち、Twitter 側サーバ内の ID の取り扱いについては以下のような明快な回答が公開されている。

http://twitter.com/twitterapi/status/2048659057

Valid points by @cwichura& @ NickMoline: we’re using a unsigned 64-bit bigint internally to store status_ids. You should, too. ^DW

(我々は status_ids の格納に、内部的に 符号なし 64bit 整数を使っている)

従って、Twitter サーバ側では既に対処済みである。Twitter の Web サイトのみを使っている場合はおそらく大丈夫。

次に、サーバから送られる Twitter のフォーマットについては、次の資料を見ていけばわかる。

• Twitter API Documentation
• Twitter REST API Method: statuses public_timeline
• Return Values

Twitter サーバのデータフォーマットは xml, json, rss, atom の4つの形式から選択できる。いずれもテキストフォーマットであり、バイナリを含まないため、フォーマット自体には桁あふれや解釈の違いによるデータ化けは原理的に発生しない。

Twitpocalypse のサイトで指摘しているのは、３つめのクライアント側の処理である。API では変数の bit 長や最大値、型は指定されていないので、クライアント側で十分大きい値を受けられる変数に格納できているかで勝負が決まる。またはパーサの仕様により全ての数値を読み取られるようになっているか。

32bit 符号付き整数型 (C言語でいうところの signed long int) で格納した場合、2,147,483,647 に 1 を足すとオーバーフローを起こして -2,147,483,648 となる。前回読んだつぶやきから最新のつぶやきまでを表示するというタイムラインの処理の場合、前回の つぶやき ID を保存しておいて、ダウンロードしたつぶやき ID と比較する処理を行うはず。負の値になると上下が逆転するのでそれ以降のつぶやきは表示されないかもしれない。

また、Reply を送信する場合、相手のつぶやき ID を in_reply_to_status_id に格納して送信する仕様になっているが、Twitter クライアントが負の値で文字列にしてしまうと、サーバ側で ID と異なる数値を受け取るので、受け取ってもらえないかエラーになる可能性がある。

さて、手元には何種類もの Twitter クライアントがある。Mac 用には Tweetie, Twitterific, iPhone 用は Twitterfon, Twittelator Pro, Tweetie, Twitterific Premium, Fasttweet。Adobe AIR アプリの TweetDeck もある。

今のところ、6/13(土) の日本時間 16:30 ごろに 2,147,483,647 を越える見込み。どのクライアントが生き残るのか、直前にアップデートされるのか、全滅なのか、実は全く問題がないのか。注目していよう。

公開されている Web系の日記や blog に(自主的に)書き連ねている人たちは、何かを語りたいという欲求があるのだと思う。中には大量のリンクと広告だらけで自分の言葉がほとんどない、くだらないサイトもあるけども。

そんな中、Twitter に出会って様子が変わってしまった。iPhone 3G の発売日に徹夜で並んだ時、共に並んだ人に誘われて始めたのがきっかけだった。

無償の iPhone 用のクライアントが公開され、まさに思いついた瞬間に「つぶやき」を投げるようになった。ハッと思いついたり考えたりしたことが、記憶の片隅に消えてゆかず、文字として残る。Twitter の技術者は、リプライ機能はつけたくないらしい。Twitter は掲示板やチャットではなく、マイクロブログであり、個人がいま何を考えているかを集めるのが目的だからだろう。

さて、日記にもならない、文章にもなってないメッセージを書いていると、まとめるのもおっくうになってきて、blog をあまり書かなくなってきた。文章で飯を喰っているわけではないので、公開した安心してしまうらしい。

1日で書ける文書量には限界があるので、Twitter に時間をどんどんとられてしまう。それどころか電車で移動する時間を Twitter の読み書きに使うようにもなった。iPhone でオフラインで blog を書けるように環境を整備したのに予想外である。

そんな中、サンフランシスコ市では市民の声の受付窓口に Twitter を追加したらしい。個人的なつぶやきを書き連ねるという当初の主旨からは大きく越えて、行政も注目しているようだ。一応認可制なので、くだらないメッセージで埋め尽くされて機能マヒに陥らないよう手は打っている。

そういえば、NASA の宇宙飛行士が国際宇宙ステーションから Twitter に状況を流すなんてこともしている。世界的には普及が始まっているものの、日本のマスコミではまだあまり聞かない。もしかしたら NHK が生放送中に Twitter での意見を受けたり、日本の芸能人がプロモーションで使うようになりそうな気もする。

WordTwit 2.0.2 を入れたら Twitter に通知が行かなくなってしまったと思っていたら、Apache の error.log を見たら MySQL の呼び出しでエラーが出てるし。

本家のフォーラムでも調べてみるかと思ったら WordTwit 2.0.3 がリリースされていた。アップデートしたら解決。

もう一つ、WordPress の設定画面を眺めているとよく見かける Gravatar という単語。一体なんだろう。

どうも メールアドレスをキーにしたアバター画像登録サービスらしい。WordPress は 2.5 以降に対応していて、コメント投稿者のアバター画像をメールアドレスから引いてきて自動的に表示することができる。WordPress 以外では CPAN や github でも対応しているとのこと。最近の標準なのか。このへん に各アプリケーションや言語ごとのライブラリが用意されている。

Web アプリケーションごとにアイコン登録するより簡単でいいな。