由於寫文件的速度趕不上設計變更的速度,所以以下資訊可能與最終版本不同,一切以 Miro Board 上的設計圖為準!
使用者透過掃 QR code 連上 WebServ(位於阿里雲上的 ECI docker)
NOTE: 開 webpage 不需要 server 也可以開得起來,第一次連線後本機會存一個 cache file。webpage 裡面會透過設定參數決定是否需要連線遠端更新或是使用本地的資料。這樣的技術就是 PWA – Progressive Web App。
ATM 將收到的兩個 RNA 上傳到 WebServ 後,WebServ 會計算出一組 RNA-pair。但 WebServ 此時無法 response 到 UE 端。因為送出 request 的人是 ATM。那麼 UE 端要怎麼接收更新呢?– 每次 UE 重新開啟 webpage 的時候,才會從 WebServ 得到需要更新 RNA 的通知。
每一個裝置都會有一個唯一性的 deviceID 紀錄在 WebServ,UE 第一次連線時會將這個 deviceID 送給 WebServ 紀錄。之後 UE 的每次連線,都會將 deviceID 夾帶在 token 送給 WebServ。所以 WebServ 能夠知道這個連線來自於誰。
ps: 如果 UE 端 reload WebServ URL,因為沒有改變任何事情,看起來就像什麼事情都沒發生,只有動畫會重跑。
UE 每次跟 WebServ 溝通時只要是新用戶,就會進行上面的流程。過程中的 RNA 其實算是一種「類發幣」的行為,RNA 會由 {A,B,C,D} 四種病毒株組成。只要有一個 UE 連進 WebServ,WebServ 就會依序發送 x*{A,B,C,D},並以 RNA 的格式呈現。x 是固定值,假如程式碼裡設定 20,則:
第一個連進來的人,拿到由 20A 組成的 RNA;
第二個連進來的人,拿到由 20B 組成的 RNA;
第三個連進來的人,拿到由 20C 組成的 RNA;
依此類推
NOTE: 不管如何,「幾A幾B幾C幾D」都可以透過 hash() 轉換為 RNA 格式。當我們提到 RNA 的時候,單一 RNA 的 hash string 是可以解出含有「幾A幾B幾C幾D」的。
感染的系統行為操作就是將兩個不同亞型病毒的人交換彼此的病毒株數量,但是仍會維持總量固定。ex:
Alice 的 RNA 含有 20C,Bob 的 RNA 含有 20D,兩個人在 ATM 機前互相感染後,最終 WebServ 可能會產生:
10C10D, 5C15D, 16C4D, 8C12D… 等等的任意兩個 RNA,並且指派給 Alice 和 Bob 的 deviceID。
等到 Alice 和 Bob 再次打開 UE browser 的時候,會提示要更新 RNA。這時候才會從 WebServ 把新的 RNA 更新回來。
ps: Alice 在 ATM 前掃完 QR code 之後,ATM 會在接下來的 5min 內等待下一個人掃描 QR code,如果沒有就 timeout,不會處理 Alice 的 RNA(一切重來的意思)。
當 Alice 和 Bob 做 RNA 交易的時候,WebServ 端會更新這兩個人的交易次數(+1) infect_count。次數是影響最後將 RNA 換算成多少價值的參數。
目前沒有這個機制
這次也會有病毒衰減的行為,但是衰減期要拉長,避免需要觀眾經常跑去展間(考量北京的交通距離和觀眾習慣)。