プロトコルはプログラムとサーバーが互いに通信する方法を決定するため、ほとんどすべてがその選択に依存します。 そして、クライアントがどのように配置されるか、そしてファイルを扱うことでどのような能力を持つか。
今日、WebDAVを選択し、 Yandex.Diskクライアントのプロトコルにした理由についてお話したいと思います 。
それに基づいて実装されたAPIのおかげで、 ABBYY FineScanner 、 Handy Backup 7 、 ES Explorer 、およびLinux用の非公式のYandex.Diskクライアントは、すでに当社のサービスで動作しています。
プロトコルを選択する前に、最も重要な要件を特定しました。
- 作業速度;
- オープンライセンス;
- 必要なすべてのアクションを実装する機能：認証、ファイル操作のサポート、ファイルへの競合アクセス、サーバーからの再開、サーバーへのダウンロードの再開。
- 普及率-ターゲットOS（主にWindows、Mac OS X、Linux）で「そのまま」、または最小限の修正で動作するはずです。
既存のプロトコルが私たちに合わない場合は、独自のプロトコルを開発する準備ができていました。 起動後にプロトコルを変更するには多くの工数が必要になるため、さまざまなオプションを検討し、要件を満たす最適なものを選択する必要がありました。
FTP ファイルを使用したリモート作業用のこのプロトコルは、実績があります。 しかし、情報セキュリティ要件を考慮せずに作成されたため、私たちにとって大きな欠点になりました。 さらに、たとえば、ファイルのコンテンツとともにメタデータを転送するなど、必要な操作の多くをサポートしていません。 また、接続するには特別なアプリケーションが必要です。
BitTorrent すぐにデバイス間の同期について話しているので、サーバーに負荷をかけずにデバイス間の接続を使用することは非常に便利ですが、これにはクライアント開発での二重の作業が必要です。 さらに、NATおよびファイアウォールを介して作業するときに問題が発生し、このプロトコルを使用する利点が大幅に低下します。
Amazon S3 このリポジトリは、独自のHTTPベースのプロトコルを使用します。 API S3を使用する可能性を検討しましたが、ディレクトリ内の通常の作業が不足しているため、アクセスに特別なアプリケーションを使用する必要があるため、このアイデアを放棄しました。
WebDAV HTTPとXMLに基づいており、簡単に拡張可能で、仕様で必要なほぼすべてをサポートします。 すべてのターゲットオペレーティングシステムにプリインストールされたパッケージは、非常にうまく機能します。 さらに、Yandex XMPPサーバーを扱ったYandex.Diskデスクトップクライアント開発部門は、その時点ですでにオープンXMLベースのプロトコルを操作した経験がありました。
独自のプロトコルを作成したくない主な理由は、アプリケーションだけがそれを使用できるため、オープンであることを望んでいたためです。
その結果、説明したすべてのオプションのうち、WebDAVを選択しました。 プロトコルに欠けている唯一のものは、同期の非常に重要な機能であるサーバー上の変更についてクライアントに通知することでした。 しかし、プロトコルは拡張可能であるため、これは問題になりませんでした。
プロトコルを選択した後、Yandex.Diskプロトタイプの作業が開始されました。 WebDAVサーバーはErlangで作成しました 。 Webサーバーのフレームワークとして、 mochiwebが選択されました。これは、開発者にとってかなり軽量で有名なライブラリです。 また、100万人のユーザーを1つのサーバーに接続することに関する有名な記事（100万ユーザーのコメットアプリケーション）でも使用されていました。 また、Apacheと比較できるYaws Webサーバーの使用についても考えました。 これは、静的をレンダリングし、CGIスクリプトを実行し、サーバースクリプトを使用して特別なページを処理できる本格的なWebサーバーです。 しかし、これらすべては必要ありませんでした。 プロジェクトを今すぐ開始した場合、接続の問題を特定する機会が増えるため、選択肢はCowboyになります。
WebDAVプロトコルを検討した後、サーバー上のファイルとディレクトリを一覧表示する操作の作業が開始されました。 プロトタイプのリポジトリとして、メタ情報とファイルの内容を保存するための通常のファイルシステムを含むmysqlデータベースが使用されました。 この段階でのスケーリングと高い信頼性は必要ありませんでした。
レイアウトはプロトタイプであったため、非常にシンプルでした。 通常、ファイルシステムの場合と同様に、方法の制限から疑問が生じました。 リソースへの最大パス長はプロトコルで指定されていなかったため、パスコンポーネントの長さを255文字に、ネストレベルの数を無制限にすることにしました。 おおよそ、ファイルストレージテーブルは次のようになりました。
| id | 番号、自動インクリメント、一意のリソース識別子 |
| uid | ユーザー、リソース所有者 |
| 道 | 長さ255の文字列、リソース名 |
| タイプ | リソースタイプ、ファイルまたはディレクトリ |
| 親 | 番号、所有者ID |
| 深さ | 番号、リソースのネストレベル
クエリクエリの最適化に使用 |
最初の重要なタスクの1つは、ルートをリストすることでした。 難点は、PROPFINDメソッドがリストするだけでなく、リソースのプロパティを読み取るタスクも実行することです。 リクエストを適切に分解し、発行できるものとできないものを理解する必要がありました。 正解を形成します。 最初のクライアントとして、組み込みのUbuntu gvfsが使用されました。 動作をデバッグした後、Windows 7からの接続を確認することにしましたが、動作しないことがわかりました。 他のサーバーとの連携に関する調査では、ビルトインWindowsクライアントは、プレフィックスなしでデフォルトとして宣言されている場合、「DAV：」名前空間を処理しないことが示されました。 他の標準クライアントはより寛容であることが判明し、特にWindowsクライアント用に形成された出力を簡単に消化しました。 幸いなことに、これは私たちが見つけることができた唯一の非互換性でした。
リストが完成したら、ディレクトリの作成とリソースの削除という簡単な操作を実装しました。
次に、ファイルのアップロード方法を学ぶ必要がありましたが、この操作はそれほど簡単ではありませんでした。 そして、なぜ-このトピックがあなたに興味があるなら-私たちは次の投稿で伝えます。