プロトコルについて一言...またはやかんを一緒に設計しましょう！

実際、プロトコルだけでなく、複雑なシステムの相互作用のロジックについてもです。 もちろん、これはBigDataではありませんが、まだ彼の頭と槍を粉砕する何かがあります。







開発の最初の段階で、読者がこの楽しいプロセスに参加できるように、それについてライブで話すと脅した。 そして今、時が来ました。 私たちのプロトタイプはほぼ準備ができており、現在、生産およびサーバーとモバイルアプリケーションの開発のためのドキュメントに取り組んでいます。 そして、プロトタイプは最も簡単であり、私たちがその中で解決したすべてのタスクは、幼稚園、ストラップのズボンであることに気付きました。

ツイートを送信したり写真を投稿したりするときに複雑なロジックがどのように機能するのか疑問に思ったことはありませんか？ それは目に見えず、99.9％でユーザーから隠されており、完全に見えません。 自分で設計しなければならなかった瞬間まで、私もそれに気づきませんでした。

行こう！

ここでやかんを作っています。 プロトタイプのように電話から直接制御されますが、すべてがシンプルで論理的です：



ローカルネットワーク、クライアント、デバイスがあります。 サーバー、アカウント、承認はありません。 美人 ケトルを購入して家に持ち帰り、ネットワークに接続します。 どのように接続しますか？

最初の使用

2つの事実から進みます。自宅では、ユーザーはWiFiをまったく使用していない可能性があり、まだ使用している場合、ユーザーの名前とパスワードはわかりません。 したがって、構成プロセスのユーザーは、ティーポットがネットワークにログインできるように、ティーポットに名前とパスワードを渡す必要があります。

これにはいくつかの方法があります：ボタンでネットワーク名とパスワードを入力するか、電話画面を点滅させるか、 DTMFコードでキーキーを鳴らして送信するか、アプリケーションを使用して内部にケトルを接続して設定する必要がある有名なWiFiネットワークを作成できます。 協議後、後者のオプションを使用することにしました。 これは最終決定ではなく、読者は将来のユーザーと同様に影響を与えることができます。記事の後、投票でオプションを選択してください。



しかし、今のところは、WiFi認証オプションから続行します。



デバイスを初めてオンにすると、事前に定義された名前（見つけられるように）でオープンWiFiネットワークが作成されますが、最後にランダムに挿入されます（同時にオンになった複数のダミーが互いに干渉しないように）、AVI-WifiKettle-6574のようなものです。

アプリケーションはそれに接続し、ネットワークを作成するか現在のネットワークに接続するかをユーザーに尋ね、パスワード付きの名前を要求します。 前の質問に応じて、構成終了後のやかんはネットワークを作成するか、現在のネットワークに接続します。



すべてがシンプルで明確です。 アプリケーションからデバイスへのコマンドの送信も非常に簡単に見えます。



アプリケーションはティーポットに接続し、それにコマンドを送信します。 コマンドが正しいかどうかをチェックした後（パーサーはエラーなしで機能し、デバイスの種類と言語のバージョンはターゲットに対応します）、やかんはコマンドを受け取ったと言い、実行を開始します。 コマンドが実行されると、やかんはコマンドが完了したことを報告し、アプリケーションは「Your kettle has boiled。」というメッセージでユーザーを喜ばせることができます。

タスクが複雑になります。 現在、リモート管理用のサーバーもあります。

しかし、それほど単純ではありません。 リモートコントロールが必要ですか？ これを行うには、別の要素であるサーバーを導入する必要があります。 スキームは次の形式を取ります。



それほど難しくないようです。 ただし、サーバーを1桁追加すると、ロジックの複雑さが増します。



ここで、たとえば、最初のインクルージョンがアプリケーション側からどのように見え始めたか：



承認が行われました（ケトルを有効にできる人はいません）。これはアカウントサポートを意味します。 プログラムをオンにすると、ユーザーに既存のアカウントにログインするか、新しいアカウントを作成するかを尋ねる必要があります。 どういうわけかデバイスを互いに区別するために、UUID-Dデバイス（デバイス）のシリアル番号を入力します。 これはプログラムによって生成され、最初の接続でデバイスに送信されます。 将来、ユーザーはデバイスからUUID-Dを取得できなくなり、完全にリセットして新しいUUID-Dを設定できるようになります。 同時に、デバイスのシリアル番号を知らないと、コマンドを送信できません。 その結果、デバイスに初めて接続したアプリケーションのみがシリアル番号を認識します。 シリアル番号はサーバー上でユーザーアカウント（ユーザーが作成した場合）に保存されるため、紛失してもユーザーを脅かすことはありません。 しかし、ここに新たな問題があります-デバイスは、異なるアカウントを持っている複数の人によって制御される可能性があります。 そのため、デバイスの権利を他の人に譲渡する方法が必要です。



作業の論理を複雑にしないために、権利分離のシステムを放棄し、目的のデバイスのアカウントでUUID-Dを持っているすべての人に平等な権利を与えます。 これは、最初のアプリケーションがデバイスの権限を別のアカウントに転送するとすぐに、デバイスを完全に制御し、同じ方法で他のアカウントに権限を転送できることを意味します。 これにより、誰かに権利を与えたい場合、ティーポットの「所有者」のティーポットを奪った人を探す必要がなくなりますが、従業員が仕事を辞めてアカウントにアンタイドUUID-Dがある場合、彼はオフィスのティーポットを裏切ります夜に。 また、デバイスをリセットして再度セットアップする以外は何もできません-同時に新しいUUID-Dを受信し、古いUUID-Dのレコードがアカウントとデータベースから削除されます。 古いレコードを消去できるかどうかを判断するのは簡単です。初期化中に、デバイスのMACアドレスがサーバーに送信され、既にデータベースにある場合、デバイスは再度初期化され、古いレコードは不要です。

ユニークな部屋について

ちなみに、UUIDは非常に興味深いソリューションでもあります。それを知ったとき、私は長い間幸せでした。 :)

たとえば、誰かがアカウントを作成するサーバーがあります。 または、ファイルを追加します。 または記録。 または何か他のもの、それは重要ではありません。 サーバー上のエンティティにどのように番号を付けますか？ 最初の答えは順番です。 人が写真をアップロードします-それは00001と呼ばれます。次の写真をアップロードします-それは既に00002と呼ばれ、3番目-00003と呼ばれます。 サーバーは写真に番号を付けるので、問題はありません-彼は以前にアップロードされた写真を見て、その番号に1を追加し、それを書き留めます。 すべてが素晴らしいです。

しかし、サービスは開発中であり、すでに別のサーバーが必要です。 しかし、ここに問題があります-サーバー間の同期が必要です。 また、ファイルの同期が比較的遅い場合、またはまったく同期できない場合は、最後のファイル名に関する情報が常に最新である必要があります。 そうしないと、異なるサーバーの2人のユーザーがわずかなギャップで写真をアップロードした場合、2番目のサーバーで情報がまだ更新されない可能性があり、ファイルは同じ番号を受け取ります。 そして最後に、ペティアがガールフレンドに送るためにアップロードした子猫の代わりに、ヴァシャの女の子の写真が公開されます。 そして、ピートはカードを受け取った彼のガールフレンドに、それが「単なるサーバーエラー、それが起こる」ことを証明しようと非常に努力します。 はい。ヴァシャは、ガールフレンドではなく、子猫を見つけると怒ってしまいます。



さらに、別の写真をアップロードするときにロックを提供する必要があります。情報をどれだけ速く更新しなくても、2人のユーザーが実際に同時に写真をアップロードする可能性があります。 つまり、そうするために、昇順でファイルに名前を付けることはできません。

たとえば、近い将来に一致しないように、十分に大きい乱数を生成できます。 また、アクティブにデータを変更する場合、現在の時刻に応じて生成します。2つのファイルが偶然一致する場合、2つの乱数が一致するだけでなく、同じ秒に一致する必要があります。 しかし、この組み合わせの可能性は非常に小さく、おそらく子猫が他の女の子の写真にならないためです:(

要するに、「すべてがすでに標準化されています！」 RFC 4122-Universally Unique Identifierに記載されているこのケースには既成の標準がありますが、単にUUIDであり、次のようになります：65C4B640-3452-11E3-AA6E-0800200C9A66。 。



しかし、私は十二十億のおっぱいに気を取られました。 ケトルの最初のインクルージョンは次のとおりです。



単純なデバイスアプリケーション認証と比較して、多くの新しいものがここに追加されました：デバイスにはUUIDが割り当てられ、サーバーへの接続を試みて、そこにWiFiモジュールのUUIDとMACアドレスを送信します（理由は既に説明しました）。

安全性

「デバイスはできるだけシンプルであるべき-デバイスは保護されなければならない」という矛盾について考えて、興味深い決定に至りました。 より正確には-アカウントを使用してセキュリティシステムを実装する方が便利ですが、アカウントを作成するために必要なケトルを使用すると言う人に直面するのは私が初めてです。 その結果、アカウントが作成されますが、ユーザーはこれに関与しません-上の写真で確認できます。 初期化中に、ランダムな名前とパスワードでアカウントを作成し、それを承認用のキーとして使用するアプリケーションに保存します。 ユーザーはこれを知らない可能性があるため、アカウント作成の問題は解決されました。

はい、すでに聴衆から異議を聞いています-アカウントに満足している人はどうですか？ ユーザーは自分のアカウントに複数のデバイス、複数の電話を持つことができます。または、頻繁に更新された後、アプリケーションを再インストールする必要があります。 事実上のアカウントがありますが、それらを使用することは困難です-ログインA811BF51-98B8-4604-9A8C-D72D8E40D846とパスワード7960E625-912D-4625-BC9E-08E9B3047219があることを忘れないでください:)

もちろん、そのようなユーザーを苦しめることはありませんので、アカウントの名前を変更する機会をユーザーに与える必要があります。 ユーザーは自分のアカウントが既に作成されていることを知らないので、単純さの錯覚を破壊する必要はなく、アイテムを「アカウントを作成する」と呼ぶことができます。 しかし、この下に隠れることはまさに名前の変更になります。



アカウントの名前を再度変更する機会をユーザーに与えるか、ランダムから通常の名前に変更するかを決定するかどうかはまだ決めていません。 私はこの質問をあなたの良心に任せます。投票投票では、アイテムを選択するか、コメントで意見を述べることができます。

チームワーク

そして今、私たちは最も興味深い部分-デバイスへのコマンドの送信を開始しています。 アプリケーションは次のようにします。



アプリケーションは、デバイスに直接ではなく、サーバーにコマンドを送信するようになりました。 それでも、いくつかのアプリケーションが異なるチームで互いに殺そうとする状況が実装されています。 Petyaが家に座って、ケトルの電源を入れて温度を維持しているとします。 そして、まだ見知らぬ人の女の子とのカードのために彼に腹を立てている女の子プチは、彼に電話してやかんを温めるように頼みたくないが、彼女の電話からこれをしようとしている。 残念ながら、このresみのジェスチャーは、彼女が期待したとおりに認識されません。別のコマンドが既にケトルで実行されているため、彼女の電話のアプリケーションはエラーを報告します。 しかし、同時に、このロジックでは、コマンドをキャンセルするには、まずキュークリアコマンドを送信し、次に新しいコマンドを送信する必要があります。 ボタンを間違えて、ティー用に90度に加熱するためのボタンではなく、乳児用調製粉乳の温度（36度）に加熱するためにボタンを押したプチにとってはあまり便利ではありません。 彼は自分が間違っていたことを理解し、別のボタンを押します-アプリケーションはエラーを報告します。 ええ、そうです-コマンドは既に実行されています。 同じプログラムで別のコマンドを既に実行していた場合、確認なしでコマンドをキャンセルする追加のハンドラーを作成する必要がありました。

その結果、私たちに合った仕事の論理にたどり着きました。チームの送信元の電話から、不必要な質問なしに別の電話に交換できますが、他の電話からは不可能です。 他の人がお茶をteaれるのを防ぐのは無価値だからです。



そのため、アプリケーションはサーバーにコマンドを送信し、サーバー...サーバーは次のとおりです。



彼は権利を確認し（ここでPetyaはこの特定のケトルをオンにできます）、シリアル番号をチームに割り当て、データベースに保存し、デバイスへのオープン接続で送信しようとします。 接続がない場合は、表示されるまで待機します。 送信後、サーバーはコマンドの正常な配信に関するメッセージを受信し、それをアプリケーションにリダイレクトします。 そして、コマンドが完了すると、コマンドをログに書き込み、コマンドをデータベースから削除し、UUID-Dを使用してティーポットへのコマンドの実行に関する通知を、このUUID-Dをアカウントに記録している全員に送信します。

だから、家に近づく少女プチは、それでもやかんが沸騰したという通知を受け取り、彼女が到着してやかんを温めていたことを理解し、最後にこのクソはがきのためにペティアを許します。



そして、サーバーからコマンドを受け取るティーポット、永遠の労働者は、それを実行する以外に選択肢がありません。



もちろん、「Command Execution」という小さなボックスの下では、ブロック線図は劣らず（またはこれよりも大きい）ですが、これはまったく別の話です...



いつものように：

1）プライベートで文法と句読点のエラーを報告する

2）論理、文章、思考の誤りについて-コメント。

3）Srachの配置-許可されています。

4）やかんを作る男を購読する 会社のページ （購読ボタン）

5） ここでフルサイズで画像を表示できます。

6）そして、 ここからMac用のOmniGraffleプログラムの形式でソースを入手できます 。 理由はわかりませんが、突然誰かがそれを根拠にすると喜んでいます。