omaha‎ > ‎


注意: TOEIC400点とかの人の訳なので、あまり信用しないように…


The Omaha project provides a shared autoupdate and install system for Windows client products at Google that works on multiple Windows platforms, including Windows Vista. Goals include the following:

  • One autoupdate mechanism which allows teams to roll out updates with no dependencies on other product teams, without having to write their own client or server logic
    • One autoupdate server that handles all autoupdate requests - each product team will not need to roll out and manage their own server
    • One desktop autoupdate client shared by all desktop client software - there will not be separate programs running for each installed application
  • A tiny meta-installer which includes the update client (and knows how to install it if necessary) and a reference to the desired application which the update client can then download and install
  • One-click web install of applications once the update client is installed
  • Support for rich update deploy logic allowing multiple tracks for public release, beta, development and "canary" experiments
  • Support for restricted user environments; for example, users without administrator privileges
  • Providing a shared runtime for other functionality common to all Google client applications:
    • Crash reporting

Non-goals include the following:

  • Support of platforms other than Windows 2000 (SP4+), Windows XP, Windows Vista, and Windows 7; in other words, we will not support OS X, Linux, non-NT versions of Windows, or any NT version of Windows preceding Windows 2000 SP4. (Although it should be possible for other platform teams to develop their own equivalent shared client and to use the same server that's being used for Windows)




  • 他の製品チームに依存せずに、チーム独自のクライアントやサーバロジックを使用せず、アップデートを公開するための、自動更新の仕組み 
    • 全ての自動アップデートリクエストを扱う1つのアップデートサーバ - 各プロダクトチームは公開作業や独自サーバの管理をする必要がなくなる
    • 全てのクライアントソフトウェアに共有されるデスクトップ自動アップデートプログラム - 各インストール済みアプリケーションごとに別々にプログラムを走らせる必要がなくなる
  • 必要に応じてインストールを行うことができる更新クライアントや、ダウンロードやインストールを行うために予期されたアプリケーションへの参照を含む(訳怪しい)、1つの小さなメタインストーラ。
  • 一旦更新クライアントがインストールされると、ウェブでの1クリックインストールを行える。
  • 正式リリース、ベータ、開発、(Chrome) canaryのような最新機能の実験用など、複数のラインに対応した、リッチなアップデートデプロイの仕組みのサポート
  • 制限されたユーザ環境のサポート例えば、管理者権限なしのユーザなど。
  • 全てのGoogleクライアントアプリケーションの為の他の一般的な機能についての、共有ランタイムの提供。 
    • クラッシュレポート

  • Windows2000(SP4+), WindowsXP, WindowsVista, Windows7以外のプラットフォームのサポート。
    言い換えると、OSXやLinux, NTバージョン以外のWindowsや、Windows2000SP4より前のWindowsはサポートしません。


Google client products have the capability to update themselves to a newer version without end-user intervention. This capability is called "autoupdating."

Although our client products shared the autoupdate feature, they did not all share autoupdate code. Some had implemented their own autoupdate solutions, and others had taken advantage of the common autoupdater code and the common autoupdate server.

It was obviously desirable for products to avoid unnecessary duplication of code and for Google to avoid maintaining multiple servers that perform identical functionality. This reason alone was enough to consider unifying all client products under a single autoupdate solution. In addition, the evolution of Microsoft Windows made this unification almost mandatory. Windows Vista features a strict security model that limits the ability of most applications on a machine to perform system-changing activities, such as modifying the Windows registry, writing to the Program Files directory, or in some cases writing any persistent change to the system at all. Updating a program installation requires all these capabilities; thus, on Vista, most traditional autoupdating will fail.

Another problem caused by lack of shared code is that each autoupdate mechanism had its own subset of desired features. Most did not have a way to do canary experiments. Most did not have a way to have multiple update tracks. Most did not define a consistent versioning mechanism. Some of these features were not optional as user base size increased. By unifying the code we could deploy a rich set of autoupdate capabilities to all client applications.

Also, as the number of Google applications increased, it became more and more desirable to improve the overall install user experience. The browser typically prompted the user with a long series of techy, confusing and scary dialogs all trying to convince the user not to install. Then the user was prompted with a wizard filled with choices that they did not need to or know how to decide amongst. These factors combined to form a bad user experience and large drop-off during the app installation process.

To address the goals of Vista compatibility, reduction of duplicative effort at Google, improvement of deploy and autoupdate capabilities, and application install user experience improvement, we proposed to develop shared client infrastructure that handles all installation and autoupdating tasks for Google Windows client products. This client communicates with a single Google autoupdate server. Taken together, this server and client is named Google Update. The project code name is Omaha. 




必要のないコードの分離を避けることは、製品に明らかに望まれていましたし、Googleでは、複数の同等に振舞うサーバをメンテナンスするのは避けることが望まれていました。それだけに1つのアップデート方法の下で全てのクライアントを統一することが検討されました。加えて、Microsoft Windowsの進化は、この統一をほとんど強制的にさせました。WindowsVistaは、レジシトリを変更や、Program Filesディレクトリへの書き込みや、システムに対して権限の変更を行う場合、すべてにおいて、システムの変更を行うために、ほとんどのアプリケーションの機能を制限する厳格なセキュリティーモデルが特徴です。プログラムインストールの更新では、それらすべての機能を要求します。従って、Vistaでは、ほとんどの旧来の方式の自動アップデートは失敗します。





それらの目標に対処するため、我々はGoogleのWindowsクライアント製品のために、全てのインストールや自動アップデートを扱う、共有クライアント基盤の開発を提案した。このクライアントはGoogleの自動アップデートサーバに通信する。まとめると、このサーバとクライアントはGoogle Updateという名付けられた。そのプロジェクトコード名がOmahaである。

High Level Requirements

Solve pushing server content and binary changes at the same time
Allow our partners to add their own versions of their product to Omaha without our intervention or a server push on our end
Allow our partners to be able to test new versions integrated with Omaha without making the URL live to the rest of the world
Be able to offer different versions of the same product, including beta software at different URLs
Continue to support at least as good one-click install experience as we have now
Offer better non-admin/limited user account support, i.e. downloading and running the product over offering a link
Be able to install product updates without the product running
Optionally be able to automatically run the product after the installation completes
Be able to show no UI vs. a small progress bar - e.g. Earth install vs. Offline Gmail
Provide decent proxy support, i.e. reliable downloads outside the browser
Optionally don't require interactive installers/uninstallers for Omaha so product teams can rely on our translations for them.
Offer a small stub executable
Make the Omaha UI super fast to load
Omaha to support localization in the top X languages 
Be able to save the installer for later use




Omaha consists of three principal parts: a client-side run time, a meta-installer (which simply wraps the client run time and either the application installer or a micro reference to the application), and a server. The client and server communicate with each other over HTTP or HTTPS. When a user wishes to install a new Google application, in actuality he or she merely downloads a meta-installer wrapping the selected application, which either installs the client or confirms that the currently-installed Omaha is up to date, and then exits after requesting that Omaha install the desired Google application. If that application is not already installed on the user's system, the Omaha installs it (using the wrapped installer or downloading the most recent version from the server). Omaha then periodically checks for updates to products installed on the system, and when appropriate, installs those updates. Omaha also provides elevated-privilege functionality to lower-privilege Google applications on the system.

New Install

User downloads a meta-installer from a Google website, going through standard browser file download steps. Once the user figures out how to launch the meta-installer, the meta-installer installs and runs the Omaha client. On Windows platforms, such as Windows Vista, with UAC, an elevation prompt is displayed when installing applications per-machine. The client then begins downloading and installing the app referenced by the micro reference.  

Secondary Install

Google website detects that Omaha client is installed, and instead of delivering a downloadable EXE or MSI, it vends an application micro-reference via an ActiveX (or equivalent) object. In this case, the user didn't have to go through any complicated download steps. They just clicked on a web link and the download starts. The rest of this scenario is the same as the initial install scenario.


Omaha uninstalls itself when there is no application registered with it for updates.

The overall sequence diagram is below:

  1. For organic installs, the user downloads an installer called AppNameSetup.exe, which is actually the Omaha meta installer plus a data tag containing the name and ID of the managed app (AppName, in this case)
  2. Execution of AppNameSetup.exe installs Omaha.  Omaha reads the data tag (to get the name of the app it's installing) and immediately contacts the Update Server to get the download location of the current version of AppName. The AppName installer is downloaded and executed on the user PC.  Omaha itself takes no part in the installation process; it merely executes the provided installer
  3. Omaha periodically (every 5 hours, as of this writing) checks for updates for all of its managed applications.  If an update is available, Omaha downloads the indicated binary and executes it

There is also support for offline installers (Omaha and the AppName installer bundled into the initial download) and partner distribution








図 略
  1. 本格的なインストールでは、ユーザはAppNameSetup.exeと呼ばれるインストーラをダウンロードし、それは実際はOmahaメタインストーラに、管理されたアプリの名前(この場合はAppName)とIDを含むデータタグを足したものです。
  2. AppNameSetup.exeの実行はOmahaをインストールします。Omahaは(インストール中のアプリの名前を取得するため)データタグを読み取り、AppNameの現在のバージョンのダウンロード場所を取得するために、即座にアップデートサーバに通信します。AppNameインストーラはユーザのPCでダウンロードされ実行されたものです。Omaha自身はインストールプロセスの一部ではありません。提供されたインストーラを僅かに実行するだけです。
  3. Omahaは定期的に(この記述では5時間ごとに)、Omahaによって管理されている全てのアプリケーションのアップデートをチェックします。アップデートが有効であれば、Omahaは示されたバイナリをダウンロードし、それを実行します。

High Level Design


The Omaha client is a Windows application, installed by a custom Windows installer. It performs several functions:

  • Installs and updates Google applications for the host machine
  • Periodically talks to the update server to determine whether an update is necessary
  • Provides a simple progress UI to notify users that the initial installation of the Omaha client is happening
  • The elevation functionality in the Omaha client allows applications to update themselves even if they are running in low-rights mode
  • Provides infrastructure for applications to report crashes (from the Breakpad project)

The client is able to handle multiple downloads in parallel, multiple sequential installs, and it is able to resume or restart partial downloads.

The client is not a separate application in the sense that it can be uninstalled independently of Google applications. Instead, it is considered a required feature of applications. It will uninstall itself when the last Google app using it is uninstalled by the user.

In addition to specific reporting related to installation and update, Omaha includes a generic crash-reporting facility for Google applications. The Breakpad project's network library is used, and the client will handle local minidump storage and queuing of reports.


The Omaha client consists of two major parts:

  1. Runtime, which handles all necessary update and install services
  2. Web browser control (ActiveX for Internet Explorer and NPAPI for other browsers), which allows Google web pages and Google applications to ask the run time to do tasks on their behalf



  • ホストマシーンにGoogleアプリケーションのインストールとアップデート
  • アップデートが必要かどうか決定するために、定期的にアップデーサーバに通信
  • Omahaの初回インストールが始まったことをユーザに通知するための単純なプログレスUIを提供
  • 低い権限のモードで走るアプリケーションにアップデートを許可するためのOmahaにある高い権限の機能
  • (BreakPadプロジェクトからの)アプリケーションがクラッシュをレポートするための基盤


  1. 実行時に、全ての必要なアップデートやインストールサービスを扱う
  2. ウェブブラウザコントロール(IE向けのActiveXや他のブラウザ向けのNPAPI)により、GoogleウェブページとGoogleアプリケーションは、実行時にそれらの振る舞いによるタスクを行うため、通信することができる。

Client Runtime

The runtime has the following functionality:

  • automatic startup so that it is always available to applocations
  • on-demand privilege elevation for install and autoupdate
  • autoupdate polling
  • downloading installers from Google download server
  • execution of Google installers
  • a persistent work queue for handling parallel restartable downloads and installs
  • progress and status notification hooks for UI 
  • self-uninstall when the last registered app is uninstalled
  • reporting of install success / failure pings
  • opt-in usage stat collection
  • crash reporting infrastructure for other Google applications
  • authentication and verification of installers


  • いつでもアプリケーションを扱うための自動起動
  • インストールや自動アップデートのための要求に応じた高い権限
  • 自動アップデート ポーリング
  • Googleダウンロードサーバからのインストーラのダウンロード
  • Googleインストーラの実行
  • 並列したリスタート可能なダウンロードやインストールを扱うための永続的なワークキュー
  • UIのためのプログレスや状態通知フック
  • 最後の登録されたアプリがアンインストールされたときの自己アンインストール
  • インストール成功やpingの失敗の通知
  • 使用許諾集(?)
  • 他のGoogleアプリケーションのためのクラッシュレポーティング基盤
  • インストーラの認証と照合
Execution Model

The runtime functionality is divided between a couple of processes, most notable a core process and many worker process. There are a few reasons for the separation: robustness, running code with the least privilege, executing Google installers in the context of the logged in users as much as possible, and avoiding resource leaks and resource consumption in long-lived processes.

The execution model for the runtime code depends on how Omaha is actually installed. There are two main scenarios here:

  1. Omaha is installed for the machine. This requires the user has administrator privileges. In this case, a Windows service runs all the time as SYSTEM and, at the right time, it kicks off worker processes to do the bulk of the work. To update per-machine applications, the worker process runs as SYSTEM as well. The worker process terminates when there is no more work to do.
  2. Omaha is installed installs for the current user. Consequently, there is no service and no machine updates are possible. In this case, the execution model solely relies on a goopdate worker process that runs all the time in each interactive session as the user.

It is important the same binary works the same way on different operating systems: Windows 2000, XP, and Vista. The process execution model is almost identical, in both machine and user cases. For the most part, the machine and user instances of Omaha run in isolated security contexts and they share nothing.

The Omaha core runs in a local system process for the machine, and one process for each logged in user. Typically, there will be two core processes running. There is potential for an optimization here, as the local system process can create a process that runs as the logged in user when it needs to.

The machine Omaha core process is started at boot time by a system service that terminates soon after. There is a reason for not running the Omaha core in a service: a bug in XP prevents us from further updating the service if the service has crashed. More investigation will have to be done here, especially since having a service is quite nice and eliminates the need for another process. The user Omaha core process is started by the shell from the user's run key. To eliminate a single point of failure, there are fallbacks implemented using the Windows system scheduler to attempt to start the core process if for some reason it is not running. It should be desirable to measure the overall availability of the core process.  We strive to be as available as the Windows OS is in terms of uptime of the Omaha core.

The Omaha core is highly reliable and lightweight:

  • It does very few things well: scheduling of workers for silent updates, elevation, and support for breakpad crashes
  • Removes the core dependencies on several Windows modules: no msxml, no shell, no network, no UI, no crypto, no wintrust, etc
  • Reduces the working set and the resource consumption
  • By the virtue of less code and closer to the OS layer, the Omaha core can be made reliable, reliable, reliable
  • Everything else runs out of process

The Omaha worker processes do most of the actual work:

  • A unified IPC mechanism is desirable
  • The communication and synchronization between worker processes is kept to the minimum, according to the isolation and share-nothing concepts of the design
  • The workers use the new network stack and the new CUP - client update protocol, which uses HMACs over plain HTTP instead of HTTPS
  • To facilitate firewall traversals, a constant shell is used



  • Omahaはマシーンにインストールされる。これはユーザに管理者権限を要求する。この場合、Windowsサービスは常にシステム権限で走っており、適当なときに、仕事の大部分を行うためのワーカープロセスをキックする。マシンごとのアプリケーションをアップデートするため、ワーカープロセスはシステムと同等の権限で走る。ワーカープロセスは他にやることがなくなったら終了する。
  • Omahaはカレントユーザ向けのインストールによってインストールされる。その結果、利用可能なマシンのアップデートやサービスのアップデートは無い。この場合、実行モデルは単に、そのユーザ権限で、それぞれのインタラクティブセッションで常駐する、Goopdateワーカープロセスに依存している。
    (注: omahaにはGoopdateというプロジェクトがある)



  • ほんの少しのことを上手く行います:サイレントアップデートのためのワーカーのスケジューリング、権限付与、breakpadクラッシュのサポート
  • いくつかのモジュールへのコア依存の除去:msxml/shell/network/UI/crypto/wintrustなど
  • リソース消費やワーキングセットの削減
  • OSレイヤーへの近さと、少ないコードの長所により、Omahaコアは信頼でき、信頼でき、信頼できる
  • 他の全てのことはプロセス外で実行する
  • 統一されたIPCメカニズムには魅力がある
  • ワーカープロセス間の通信と同期は、分離と共有なしのデザイン方針により、最小限に保たれる
  • ワーカーは新しいネットワークスタックと、新しいCUP(クライアントアップデートプロトコル)を使う。それはHMACをHTTPSの代わりに簡素なHTTP越しに使用する。
  • ファイアウォールの走査を促進するため、固定のシェルが使用される(いまいち意味分からず...)
Application Registration

In order for an application to receive updates, the application must register with Omaha. The application registration mechanism is based on Windows registry. There are primarily two update policies supported by Omaha, which directly affect how an Omaha aware application registers with the Omaha runtime:

  1. per-machine updates
  2. per-user updates

In the case of per-machine updates, each application installed per-machine creates a key HKLM/Software/Google/Update/Clients/{GUID}. Under this key, the application creates the following values:

  • pv (current product version - e.g.
  • name (ignored but useful for debugging)

In the case of per-user updates, the only difference is the location to where the key is created. In this case, the key is HKCU/Software/Google/Update/Clients/{GUID}.

When the update loop kicks in, Omaha runs the per-machine updates as SYSTEM and per-user updates as the logged in user. This assumes that the user has an active session, in other words, updates for per-user installed applications will not run if the user has not logged in. As long as there is anything under these keys, Omaha keeps pinging for updates and updating these applications. It is possible that the application is dead and its registration with Omaha still active, for example, in the case where the user just deleted the application files. Unfortunately, Omaha does not detect such conditions and it is going to download and apply updates for it until the application cleanly unregisters.

Exposing registry keys and low level implementation details to applications has disadvantages. It breaks the encapsulation of Omaha. An argument can be made that such implementation details would be better to be abstracted out in a code library that the application code links with. However, there is a great advantage for the current registration mechanism. Registry keys can be created easily directly from the installer script for applications that are using off the shelf installer technology thus making the integration with Omaha easier.


    1. マシンごとのアップデート
    2. ユーザごとのアップデート
    マシンごとのアップデートの場合、マシンごとにインストールされた各アプリケーションはレジストリキー HKLM/Software/Google/Update/Clients/{GUID} を生成する。このキーの元では、アプリケーションは次の値を生成する:
    • py (現在の製品バージョン - たとえば
    • name (無視されるが、デバッグに便利)
    ユーザごとのアップデートの場合、唯一の違いはレジストリキーが生成される場所である。この場合、キーは HKCU/Software/Google/Update/Clients/{GUID} となる。


    レジストリキーや、低レベルアプリケーション実装の詳細の公開は、不利な点である。それはOmahaのカプセル化を壊す。議論により、このような実装の詳細をアプリケーションコードが互いにリンクしているコードライブラリから抽象的に出すほうが良いということになった。しかしながら、現在の登録の仕組みは素晴らしく有利な点がある。レジストリキーは、アプリケーション用のインストーラスクリプトから直接簡単に作れるので、install shelfテクノロジーのようなものを使用しなくとも、Omahaへのインテグレートが簡単である。

    Automatic Startup

    The service is set to auto run when Omaha is installed per-machine. The SCM failover mechanism is used to restart the service in case of a crash. When Omaha is installed per-user, the goopdate worker process is started by the Windows shell from HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run.


    The client runtime runs periodic tasks, such as the update check request to the server to discover updates. These tasks are kicked off by a scheduler. The scheduler code runs inside the Omaha core process. The main requirement for the scheduler is to execute a worker process once in a while.

    A lot of consideration was given to using the built in Windows scheduler instead of building our own. The windows task scheduler on Vista seems to be greatly improved. On XP and Windows 2003 there are some limitations to the windows task scheduler:

    1. Credentials are an issue with the pre-Vista scheduler. The issue is that the scheduler used to cache the credentials for the user that registered a scheduled event and if the user password changed, then the task was broken. It has been fixed in Vista.
    2. On Windows 2003 the use of the task scheduler service is restricted to Administrators only.
    3. If the machine is in a sleep state there are some hardware on which the task will not be scheduled. There are situations in which the scheduled tasks fail because of suspected ACPI interactions. One extreme case was a machine not able to schedule tasks when the LAN cable was disconnected.


    Omahaがマシンごとにインストールされたとき、サービスは自動起動するようにセットされる。SCMフェイルオーバーメカニズムは、クラッシュした場合のサービスの再起動に使用される。ユーザごとにOmahaがインストールされたとき、Goopdateワークプロセスは HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run からWindowsシェルによって開始される。



    1. Vista以前のスケジューラは権限に問題がある。問題はスケジューラが、スケジュールイベントを登録しパスワードを変更したとしても、ユーザの権限のキャッシュを使用することで、タスクが壊される。これはVistaで修正された。
    2. Windows2003ではタスクスケジューラサービスは管理者のみに制限される。
    3. もしマシンがスリープ状態になったら、タスクがスケジュールされなくなるハードウェアがいくつかある。スケジュールされたタスクがACPIイテレーションのような原因で落ちる状況がある。究極の場合では、LANケーブルが刺さってないときマシンはタスクをスケジュールできなかった。
    Resource and Timing Constrains

    The runtime follows a few constraints regarding resource usage and timing.

    Limiting resource use:

    • check to make sure we do not use all of the user's disk space
    • use little memory and delay load the modules that are not needed. This is very important for the resident core
    • try not to autoupdate unless the user has an internet connection (important for dial-up users so that we do not auto-dial their connection)
    • limit the bandwidth usage during background downloads
    • attempt to update application when the user's machine is idle


    • Check for updates at least once a day  
    • Serialize downloads and installs

    Web Browser Control  

    The web browser control exposes a high level interface to Google web pages and client applications, enabling features such as one-click web installs and rich update clients such as Pack. It needs to limit access so that only authorized Google web pages and applications have access to the services offered by the client run time. The interface is defined by very coarse-granularity functions. Rather than "download file X from server Y" it would instead offer "download application id X from Google". In the event that the client had a security hole, it's important that the interface limit the amount of damage that can be done.

    Crash Reporting

    There are two major parts to crash reporting on Windows: generating the minidump and reporting it to the server.  With Omaha, each application would still be responsible for catching exceptions and signaling Omaha to generate and transmit the minidump to Google servers. The minidump is created in a secure directory which Omaha can write to.  It has code to try to minimize possible accidental self-DDOS as a result of frequent crashes while still reporting important data, perhaps determining when a duplicate minidump was generated, or reporting the number of crashes that have been generated but not reported.


    • ユーザのディスクスペースの全てを使用してしまわないかチェックしてください。
    • 少ないメモリの使用や、必要の無いモジュールの遅延ロード。これらは常駐するコアにとってとても重要です。
    • ユーザがインターネット接続をしていない限り、自動アップデートを試みないでください。(ダイアルアップユーザにとっては彼らのコネクションを自動ダイアルにしないため重要)
    • バックグラウンドダウンロードを使用している間、バンド幅を制限してください
    • ユーザのマシンがアイドルのときアプリケーションのアップデートを試みてください
    • 1日最低1回はアップデートをチェックしてください
    • ダウンロードとインストールのシリアライズ(連続でやれってことか?)




    Windowsでは2つの主要なクラッシュレポート方法がある: minidumpの生成と、それをサーバへ送信することです。Omahaでは、minidumpを生成してGoogleサーバに送るために、各アプリケーションは例外をキャッチしOmahaへシグナルを送る責務がある。minidumpはOmahaが書き込むことのできるセキュアなディレクトリに生成される。それは重要なデータを送る一方、頻繁なクラッシュの結果によるselfDDOSによるアクシデントの可能性を最小にしようとするコードを持っています。たぶん、いつminidumpが生成されたかの定義か、生成されたけど報告されていないクラッシュ数のレポートなど。


    The Omaha meta-installer is a simple wrapper that includes the client as well as information necessary to install one or more Google applications. It performs the following functions:

    • Installs the client if it is not installed
    • Upgrades the client if it contains a more recent version
    • Starts the client if it's installed but not running
    • Queues install requests to the client for the applications that it wraps

    Our goal is that the minimal installer will be less than 172KB (which takes less than one minute to download over a 28.8kbps link at 10 wire bits per 8 data bits, representing what's likely the slowest modem still in operation today). The current size of the matainstaller is larger than that. We are looking for ways to keep the download size down. 


    • クライアントがインストールされていない場合、クライアントのインストール
    • より最近のバージョンを含んでいた場合、クライアントのアップデート
    • インストールされたが起動していない場合、クライアントの起動
    • メタインストーラがラップしているアプリケーションのクライアントへのインストールリクエストのキュー
    我々は172KBより小さい最小のインストーラを目標にしています。(今日まだ稼働している最も遅いモデムといえる、28.8kbpsの回線を通じても1分以内にダウンロードできます). 現在のメタインストーラのサイズはそれより大きいです。我々はダウンロードサイズを小さく保つ方法を探しています。


    The Google Update server is not part of the Omaha open source project. Providing updates for applications requires a server that implements the Omaha Server Protocol.

    Omaha has two server components: autoupdate and download. This separation of server responsibilities is desirable because the requirements are different: downloading large binaries takes high bandwidth and can tolerate relatively high latency, whereas small transactions such as update pings may be much more frequent but require extremely low bandwidth per transaction. These differences allow Google to provision the two servers appropriately.

    The autoupdate server provides the following functionality:

    • Responds to update pings that come from individual Omaha clients, telling them whether and how to update the set of client products on that machine.
    • Provides a rich enough configuration schema that individual product teams should not have to implement their own servers. Client products will be able to provide arbitrary flags to Omaha that will be passed through to the server during an update ping, and it will be possible to configure the server to behave differently according to the presence or absence of those flags.
    • Allows Google to run experiments on stable subsets of users. For example, a team might wish to deploy a new version of its product to 0.01% of its users for a week in order to confirm that it causes no unexpected problems before deploying more widely.

    The download server's primary job is to host binaries.  In order to support private betas and other restricted software updates, the download server can restrict access to certain downloads.



    Omahaは2つのサーバーコンポネントがあります: 自動アップデートとダウンロードです。このサーバ分割の責務は、要求が異なるため望ましい: 凄く大きなバイナリのダウンロードは、アップデートピングのようなより頻繁で、しかし1トランザクションに非常に低いバンド幅しか要求しない、小さなトランザクションの一方で、高いバンド幅を取り、相対的に高い遅延に耐えることができる。これらの違いは、Googleに適切な2つのサーバを準備することを許可する。


    • 独立したOmahaのクライアントからくるアップートピングへの返答として、そのマシンのクライアント製品のセットを更新するかどうか返す。
    • 十分に構成された高度なスキーマを提供により、独立した製品チームは、彼らの独自サーバを実装する必要はありません。クライアント製品は、アップデートピングの間で、サーバーへ受け渡す、任意のフラグを備えることが可能です。そしてそれは、それらのフラグが存在するかしないかということによって、サーバを異なった振る舞いに構成することが可能です。
    • ユーザの集合に安定した体験をもたらすことが、Googleに出来るようになります。例えば、あるチームは、広範囲にデプロイして予期しない問題が発生しないことを確認するために、毎週製品ユーザの0.01%に製品の新しいバージョンのデプロイしてもよいです。

    Rollout Process

    To the greatest extent possible, teams will be able to reconfigure their area of the update server without affecting other teams.