ユーザーのコンピューター上ではなく、リモートサーバー上でアプリケーションを起動し、ネットワーク経由でユーザーに画像を送信するというアイデアは新しいものではなく、長い間空中にありました。 同意します。新しいソフトウェアをコンピューターにインストールするには、ライセンスポリシーを理解し（気にする人）、配布キットを見つけて（できればマルウェアは含まれていません）、ソフトウェアをインストールして構成する必要があります。 さらに、ソフトウェア翻訳アプローチにより、生産的なハードウェアの必要性がなくなります。これは、タブレットコンピューターとスマートフォンの年間売上高の伸びに照らして重要になります。 はい、インターネットは巨大都市のどこにでもあります。音楽を聴いたり、オンラインで映画を見たりすることは、結局、誰もが慣れてきました。
これまでのところ、インターネットでの使用に適した完全に機能する単一の開発はまだありません。 それはダメだと思い、それをすることにしました。
よく見てみましょう
私の側では、完全に既存の、そして非常に確立されたCitrix XenAppとMicrosoft App-Vについては言うまでもなく、おそらく完全に正直ではないでしょう。 どちらの製品も大規模な組織ではうまく機能しますが、問題は次のとおりです。両方のソリューションは、サービスのパブリックプロビジョニング（つまり、インターネット）にはほとんど役に立ちません。 これらのシステムは元々顧客との統合を目的として設計されていたため、これは技術的な機能によるものです。 さらに、このようなシステムは中小企業には手頃な価格ではないため、主に大企業の問題です。 はい。クライアントソフトウェアをユーザーデバイスにインストールし、理解し、構成する必要があります。 実際には、ディストリビューターの保証にもかかわらず、どのデバイスにもクライアントは存在しません（タブレットのことを言っています。スマートフォンはまったくサポートされていません）。 言うまでもなく、製品データに基づいて公共サービスを構築しようとしても、私が知る限り、何の役にも立ちませんでした。
そして、グローバルネットワーク専用の Windowsアプリケーションをブロードキャストできるシステムを作ってみませんか？
Windowsベースのアプリケーションとは、Microsoft Windowsオペレーティングシステムの制御下で動作できるソフトウェアを意味します。 なぜWindowsアプリケーションに焦点を合わせたのですか？ すべてが非常に簡単です。Windowsアプリケーションは、ビジネス、仕事、研究、世界中の何十億人もの人々が使用する（そして重要な使い方を知っている）アプリケーションです。 Microsoft Windows用にすでに開発されたアプリケーションの数は数百万個にのぼると思いますが、これは無尽蔵の巨大な機能であり、1か所に蓄積すれば素晴らしいと思います。
エンドユーザーの理解しやすさがシステムの主要な基準として選択されたため、最新モデルではなく、ラップトップに既にインストールおよび構成されたソフトウェアを操作することに慣れている私の母親でさえ、簡単に理解できました。
別の重要な基準は、さまざまな種類の最新デバイス（さまざまなOS、タブレット、モバイルデバイス、スマートテレビテクノロジーをサポートする最新のテレビなどを実行しているパーソナルコンピューター）をサポートすることです。 ソリューションはそれ自体を示唆しました：より正確にするには 、リモートサーバーからエンドユーザーのWebブラウザー 、またはWebページにWindowsアプリケーションを変換する必要があります。 しかし、それを行う方法だけですか？
実装
それはすべて、アパートの廊下にある古いSECOND-HANDサーバーで始まり、夜遅くまでコーディングしました。 彼らが検索で試しなかったこと：彼らは、.netアプリケーションをユーザーに移植するためのソフトウェアプラットフォームとしてSilverlightを使用することさえ拒否しましたが、可能な配信アプリケーションのセットには明らかな制限がありました。 それでも、クロスプラットフォーム環境へのアプリケーションのブロードキャストに専念し、この方向からそれ以上離れることはありませんでした。 私たちの意見では、現在、アプリケーションの操作の表示をブロードキャストすることが、ユーザーにアプリケーションを「配信」するための最良の方法です。
システムを実装するには、 次のコンポーネントを開発する必要がありました。
- Webクライアントアクセスサーバー-アプリケーションサーバーとクライアントの相互作用を提供します。
- アプリケーションサーバー-キーボードイベントとマウスイベントをアプリケーションに送信し、クライアントに画像を送信し、アプリケーションを互いに分離します。
- 管理サーバー-インフラストラクチャ管理を提供します。
- ファイルサーバー-ユーザーデータのストレージを提供します。
Webクライアントアクセスサーバーを実装するために、SignalRを選択しました。SignalRは、状況に応じて最適なトランスポートを個別に選択できます。 可能性がある場合、SignalRはWebSocketをトランスポートとして使用します（不可能な場合（たとえば、古いバージョンのWebブラウザーが理由になる場合があります）-ポーリング、長時間ポーリング）。 ポーリング、長いポーリングを使用してユーザーの快適な作業に最適な速度を達成することはできませんでしたが、古いバージョンのブラウザーに対しては部分的なサポートを提供しました。
アプリケーションサーバーは、開発されたシステムの中核であり、最も難しい部分です。 サーバーで実行されているソフトウェアからの画像送信は、スクリーンショットを撮り、受信したフレームをリアルタイムで送信することにより実行されます。 イメージは領域に分割され、トラフィックを節約するために変更のみがユーザーに送信されます。 当初はDesktop Duplication APIテクノロジーを使用する予定でしたが、デスクトップ全体を複製することしかできず、ウィンドウが必要なため、放棄する必要がありました。 その結果、スクリーンショット作成モジュールは独立して開発する必要がありました。 コーデックを開発するために、FreeRDP WebConnectが「ロールモデル」として採用され、サーバー部分は自然に自分で作成されました。 キーボードイベントとマウスイベントをアプリケーションに送信するために、入力入力機能を使用してサーバー側のイベントをシミュレートします。
ファイルサーバーと管理サーバーはあまり関心がありません。そのため、これらに焦点を合わせません。
現時点では、ベータ版は次のようになります。
記事の著者によるGimpの印象派
