ページ更新: 2013-03-05 (火) (2024日前)

関連: PC/QNAP TurboNAS, Linux/Dropbox

(2008-09-24 新規作成)

Dropbox に関するメモ。役に立ちそうなことはあまり書かない予定。

目次

[編集]

情報源 #

[編集]

Dropbox #

[編集]

その他 #

[編集]

メモ #

[編集]

Basic認証付きプロキシ経由でアクセスするには (Windows編) (2008-09-24) #

インストールの途中で「Can't connect to Dropbox」とダイアログに表示される。 このダイアログの「Connection Options...」ボタンを押して、プロキシの設定を行えばよい。

[編集]

Basic認証付きプロキシ経由でアクセスするには (Ubuntu 8.04.1編) (2008-09-24) #

nautilus-dropboxパッケージのインストールは完了する。

その後に、killall nautilus すると、システムトレイ内のDropboxアイコンから「Couldn't download Dropbox」と表示される。 この時点ではDropboxアイコンに「Preference」メニューがないため、プロキシの設定を行うことができない。

実は、nautilus-dropbox はシステムトレイの表示と、Dropbox本体のダウンロードを行っているようだ。

よって、Dropbox本体を別途入手すればよい。

Problem with Dropbox on Hardy « Dropbox Forums の発言中のリンクから、dropbox-lnx.x86-0.6.382.tar.gz を入手できる。

このファイルを~/で展開すると、~/.dropbox-dist/ が展開先になる。

あとは、いったんログアウトするか、nautilusを再起動するか、Xを再起動すれば(このいずれかの手順を用いたと思うが、忘却した)、 Dropboxアイコンに「Preferences...」メニューが追加される。このメニューでプロキシの設定を行ってやればよい。

[編集]

ごたく #

[編集]

AWS 東京リージョン開設 #

(2011-03-08)

これ、使ってくれないかなあ。

[編集]

700MBのファイルを登録してみて、アップロード中に思ったこと (2008-09-24) #

環境は Dropbox 0.6.394, Windows XP Professional SP3、フレッツ光 (Bフレッツ ハイパーファミリー)、@Nifty。

ちょっと気が引けたけど、700MBのZIPファイルを登録してみた。

現在、6時間が経過。 (01:30〜06:44)。さすがに無茶だったか。とはいえ、アップロード中にも他の操作ができるのは便利だ。

(結局、7時間で止めた。)

ちょっとだけパケットキャプチャして眺めてみた。

TCPは80(http)が1本、443(https)が1本。httpsはパケット6つ、8553バイトを送るごとに、ACKが6つ、まとめて届く。

SSL/TLS Record Layerのレコード長も8224バイト程度。つまり、SSL/TLSのレイヤのバッファ長が8224バイト未満(たぶん8KB=8192バイト)でflushしている? SSL/TLSなら上位はNO_DELAYしてるだろうから。

それとも、TLSより上のレイヤのバッファ長が8192バイト? 暗号化処理のブロック長+パディングってどれくらいだっけ? SysinternalやMicrosoftのツールでTCPの方のバッファ長を調べられるのがあったかも。

手元のWindowsのスライディングウィンドウサイズは最大65535バイト (XP SP3のデフォルト値) にしてあるけど、生かせていないので勿体ない。

Round Trip Timeは200msを超える(pingしても応答がないけど、tracerouteするとアメリカまでで200ms程度あることが判る)ので、もっとまとめて送らないと速度が出ないはずで。

もっとも、ネットワークエミュレータ (lineeとかdummynetとかShunra VEとか) でRTTを200msにしたら、100Base-TXでもiperfで1MB/sも出ないような気もする。

クライアント側はメモリが潤沢にあるだろうから、64KBのバッファを取ってもよいだろう。

でも、サーバ側もたぶん64KBないと、フローコントロールが働くよなあ。フローコントロールのパケットを抑制しようとすると、10,000接続×64KB だとバッファだけで625MBのメモリが必要、送受信両方ならさらにその倍が必要だろうし。 (1サーバで2,000接続くらいに抑えるなら1/5で125MB、送受信両方で250MB)

アップロードは当然ディスクへの書き込みが発生するし、すべてライトキャッシュに収まるわけじゃないから、 平均で秒1Mbitで、10,000接続だと、10000Mbit = 10Gbit = 1GB/s のストレージが必要。 2,000接続だと0.2GB/s = 200MB/s で、IntelのSSDでなんとか追いつくかなあ。Amazon S3ってどれくらいの書き込み速度が出るんだろう。

途中の回線品質が低い場合があることも考慮すれば、こまめにフラッシュしたほうが再送データが小さくなるから良いのかなあ。 でもキャプチャを見てると、最大ウィンドウサイズのままなので、自宅とDropbox間の回線品質はかなりよいようで。

それに、Amazon S3はSelective ACKやTCP window scalingに対応してるから(Amazon Simple Storage Service - Developer Guide (API Version 2006-03-01))、Dropboxももっと速くできるかも知れないし。

なお、PreferenceのMaximum upload rateがAutomaticだったので、これをunlimitedにして、Dropboxを終了→再度起動したが、変わらず。 (でも、途中で止めても再開できる、ってのはすごく便利だ。もしかしたら最初から転送してるかも知れないけど)

まあ、現在はbeta版だし、サーバを主な国に置いたらRTTも小さくなるからバッファの使用時間が減るので、そのときにバッファ長を大きくしてやればよいのかも知れない。そういう課題を見つけるためのbeta版でもあるわけだし。

などと、アップロードが終わるまでの間に余計なことを考えたり調べたりしてしまうので、アップロード完了予定時間を表示してくれると、余計なこと考えずに安心して時間まで寝ると思うんだ、うん。