學運現場無網路的通訊解決APP方案

最後編輯:2014-11-11 建立:2014-04-05 歷史紀錄

    小俞YU關於

  • 佩承 劉發起人/拋磚人:Lrills
  • 狀態: 集結各路好漢
  • 專案簡介:
    • 學運現場的無網路解決app方案
      • venev參考「在會場中建立可靠的訊息傳遞網」 https://g0v.hackpad.com/d6rh3bXemcK 兩案坑主可協作討論
        venev
  • 工作目標:
    • 短期可能目標:快速開發提供反服貿運動使用
      Clement Chen要offline地傳送事件訊息、GPS經緯度、案發現場圖片到一server端
    • 長期可能目標:創造一個開放源碼的無網路通訊協定
  • 授權方式:
  • 使用資料:
  • 徵求夥伴(有興趣直接簽名):
  • NeedsWriter (撰寫基本資訊、報導專案 etc):
  • NeedsDesigner (介面設計):
  • NeedsData (擷取整理資料):
  • NeedsTech (程式、架站 etc):
  • NeedsProcess (設計作業流程):
  • NeedsTalkingToRealPerson (需要真人溝通協調):

 

    小俞YU發想提案

佩承 劉http://www.ptt.cc/bbs/FuMouDiscuss/M.1396630334.A.53A.html

ptt發想連結

 

CLEMENT C--

 

目前想到的p2p流程圖如下,有要更正請幫忙指出:

A:案發現場人士、Z:3/4G對外使用者(一般是現場糾察)

節點間通訊用WiFi-D或BT

為了時間上要加速實現,目前簡單用一個節點通報兩個節點,若遇到重複就pass掉重連

 

A---通報--> B---通報---->D 以此類推, 直到傳到Z 去連結server回報訊息

B也通報 -->E

A也通報->C-通報-->F

C也通報-->G

 

CHANG Y

 

MOSI W--

 

    佩承 劉其實有個很基礎的問題,就是你做成APP的話,沒有SERVER,要是在網路連線困難的情況下, 大家一開始還是沒有辦法下載XD
    佩承 劉所以可能要另外做出「任何人只要有裝APP 就可以成為第0台SERVER,雖然沒有企業CERT,但是最起碼可以提供APK給ANDROID USER下載安裝連上....」

 

    佩承 劉對 大概想法是這樣但是沒有相關通訊軟體的經驗沒什麼頭緒...但是web app沒辦法控制到裝置上的藍芽...
    佩承 劉是的!! 希望能解決330那種狀況

 

    佩承 劉你一樣是native app啊 ...
    佩承 劉要快速做出來的話可以考慮直接寫HTTP SERVER + 跑在 WEB SERVER上的 APP
    佩承 劉不過因為現在立法院外面網路順暢 甚至有 g0v 的免費 WIFI AP.....
    佩承 劉所以回過頭來 這個project是不是定義成 "無網路環境下的區域通訊解決方案(含LOG)" ?
    佩承 劉其實我記得 g0v 有個很類似的坑..... 但是要找找看

 

    佩承 劉我個人認為這個APP最需要的權限是 強迫關閉手機 3g 連線XD
    佩承 劉然後自動挑幾隻當樹最上面的 node ,用 3g 連出去
    佩承 劉就跟直銷一樣...... 一路往下擴散傳資料
    佩承 劉每層 node 之間 sync 而不是p2p在 sync
    佩承 劉因為你要解決的是 330 那種 10k級的人數

 

    佩承 劉會希望有頻道的功能分流,每個node建立起一個識別資訊,識別所屬的頻道
    佩承 劉所以是把群眾分流程幾個區塊,各用一個節點連上server這樣嗎?

 

    佩承 劉如果如果是iOS的話可以做到給每個裝置一個識別資訊,搜尋附近所有的頻道。

 

    佩承 劉恩一開始想的是透過每個peer發布出去的時候可以自帶一個peer的info(4KB以內的dictionary),從這裡來作識別,如果要提供列表資訊的話會變成一定要連上internet嗎?

 

    佩承 劉不是一定要連上 internet
    佩承 劉是在 user 推廣觀點.....
    佩承 劉今天一個 new user 進入你的場域
    佩承 劉有裝這個 APP 的人當然不用說 他們知道要開
    佩承 劉那沒裝的人呢?
    佩承 劉所以你↓↓看下面

 

    佩承 劉這個其實你不配個在 internet 上的統一入口
    佩承 劉是沒辦法把 user 導進你的 intranet 或是 darknet 的
    佩承 劉但是總而言之 無論 user 是在 intranet 還是 darknet
    佩承 劉進來之後就是給他頻道列表讓他選 他再直接連上 primary node

 

    佩承 劉坦白來說 如果沒有 g0v
    佩承 劉這種遊行現場的網路解決方案
    佩承 劉如果我要玩 那就是幾組 wimax+wifi ap,但是停留在 intranet 上
    佩承 劉讓user全部都連上我的 ssid 進我的 intranet
    佩承 劉然後我用幾台 android 機器跑 httpd server.....
    佩承 劉一切都是 web app 這樣XD
    佩承 劉你要實作 open garden (firechat...)當然沒有問題啊
    佩承 劉問題是官方也才剛實做完XD

 

    佩承 劉好像真的是比較實際的做法...我沉澱一下下XD

 

    佩承 劉也不是沒人再ios作http server唷 應該超多XD
    佩承 劉因為我看我每隻 player 跟 pdf reader 都有內建上傳檔案進APP用的http server 啊

 

    佩承 劉綜合另外一篇看了一下稍微懂了一點...
    佩承 劉所以綜合一下可能的方案會是1.intranet 2.由可連線的node推播(如另一坑方案) 3.firechat方案
    佩承 劉

 

    小俞YU技術分析與討論

佩承 劉可行方案優缺點分析:

1.intranet

  • 優:
    • MOSI W可快速由現有資源搭建或者修改,甚至不用上架到兩個 store
      • 活動現場支援用backpack ,真的包成一個背包出團,例如: Server pack: wimax + wifi ap + nb + nb用行動電源 + webcam
      • Live pack: wimax + 行動電源 + iPad
    • g0v線路松支援後,可以直接從 intranet 變成 internet (*1)
  • 佩承 劉缺:
    • MOSI W主辦單位或有心路人需在活動前準備好 Server pack 帶過去現場
    • 每個 server pack 的 session 數被 ap 限制
    • 因為是 s/c 架構,所以 server 的負載度需要考慮一下 ( node.js / Golang / backbone.js ....)

佩承 劉2.由可連線的node與雲端相連

  • 優:
    • 節省 3g 資源
    • 不論地點平台都能加入
  • 缺:
    • MOSI W需有前幾個 node (或者主辦單位都會裝的話那倒是不用煩惱)
    • 佩承 劉3g收訊死角造成盲區
    • 群首整組消失時? 例如整群人被水柱噴濕 offline

3.firechat(*2)

  • 優:
    • MOSI W去中心化
    • 不論時地都可使用
    • 佩承 劉只要中間有node串接,理論上支援範圍無限大
  • 缺:
    • MOSI W須先下載APP
    • 聽說目前版本iOS和Android不互通? (查證中...)(*3)
    • 佩承 劉p2p同步較無效率,可能無法負荷如330遊行10k up人數(*4)

*1

    Clement ChenWiMAX hotspot 或WiFi AP support連線user數也會受限
    Mosi Wang如果把 wifi ap 的天線拔掉似乎可以透過距離縮短來減少使用人數? (誤
    Chang Amy Yu-Tzu可是不巧全球一動大力玩是內建天線(毆
    Clement Chen一般WiFi AP都可以簡單調整發射功率,看看大力玩是否也可調整WiFi的發射功率。如果不行,只好拿鐵便當盒蓋住XD
    楊佑仁WiMAX 確定要淘汰了,未來 device 已經頃向 LTE
    Clement ChenFD-LTE系統中華電信會較先設立,目前已經cell plan中。至於WiMAX就看會不會就地升級成TD-LTE,不過device是絕對不相容的XD。但dervice都會弄成大力玩型態(誰叫WiFi普及率這麼高),所以對APP設計(若是經WiFi-4G系統連上網)基本上影響不大

CLEMENT C*2

    Clement Chen從另外一篇文章看到有qaul.net跟Telegram都有同樣類似的效果,也可以download到手機試試看,我先借幾個Android手機來試試看這三個APP的實用性
    Clement Chen我用了10隻Android手機試了firechat,一起打開的時候,只有3隻手機互相連線成功,剩下的找不到彼此。當中完全不知道是哪3隻手機連線中,只有講話的時候才會顯現出手機ID。而且若其中一隻手機從中途離開後重新連線會沒辦法看到兩隻之前傳送的訊息。

佩承 劉*3

    佩承 劉可能解法 1.android透過wifi監聽iOS device發布的bonjour服務(理論可行,但找不到實作的例子) 2.BLE (但android端有bug待解決)
    Clement Chen剛請朋友測過Firechat的iOS跟Android連通,互相找不到dervice。所以可以由iOS一個大group,Android一個大group往下去sync資訊,只要iOS跟Android兩個節點的資訊同步即可!? android也有firechat
    Chang Amy Yu-Tzuandroid是用什麼跟ios的firechat測的阿? 哦哦?上次我沒找到的說。我現在看到了

 

*4

    Mosi Wang其實應該說 10K up 到底 p2p sync 要花多久...
    佩承 劉如果10層內可以傳完所有node應該是很快的,但是無法徹底解決對同一node重複播送的問題
    佩承 劉
    Clement Chen我想問節點間的傳輸是always連線嗎?用bluetooth或WiFi?對外看起來可用WiFi或3/4G。Open garden提到用Bluetooth跟WiFi-Direct(Android4.x以上支援,這門檻會過高嗎?==>ok),當然可以用Bluetooth連線。WiFi點對點我們有測過,大約戶外30公尺算極限了,bluetooth理論上會更短,不過傳message bluetooth應該絕對夠用。
    佩承 劉ios multipeer的話是apple已經幫包裝好搜尋所有wifi or bluetooth下的peer
    楊佑仁Android 4.x market share 已經過半,理論上市場接受度是可行的 http://developer.android.com/about/dashboards/index.html?utm_source=ausdroid.net
    楊佑仁另外,節點間的 http 持續連線方式是不可行的,keep connection alive 會占用 device 資源,當量一大就會 crash,除非能確保 one-to-one
    楊佑仁想了解一下,wifi或bluetooth有辦法判斷距離嗎?例如訊號要多高才進行連線和資料傳輸,以這種方式篩選附近的人數
    Chang Amy Yu-Tzuandroid 有 getScanResult( ),ScanResult 裡面有個值叫level可以得知wifi訊號強度(單位dBm)
    Chang Amy Yu-Tzuhttp://developer.android.com/reference/android/net/wifi/WifiManager.html#getScanResults%28%29
    Chang Amy Yu-Tzu藍牙的似乎有個RSSI值是強度(單位dBm)
    Chang Amy Yu-Tzuhttp://stackoverflow.com/questions/15312858/get-bluetooth-signal-strength
    佩承 劉想問一下在場對於開發進度的想法!要討論出一個雛型直接進行開發,或是先整理的完善一點,在4/19號的hackthon現場開發!?
    小俞Yu想詢問一下目前開發進度?因為昨天出關就遇到這種困擾,還差點誤事..XD
    波卡Poka直接 UDP 廣播封包會不會更省事?
    Clement ChenUDP廣播很省事,但怕packet loss,尤其人一多,更怕不知道誰有掉誰沒掉,這變得要想辦法克服packet loss。
    Chang Amy Yu-Tzupacket loss的問題可以考慮用forward error correction來解, 不過缺點是會把其他tcp流量打趴

 

波卡POKA4.Zigbee 微型外接通訊設備

  • 參考資料:http://zh.wikipedia.org/wiki/ZigBee
  • 優:
    • 支援大量網路節點的網路拓樸
    • 省電
  • 缺:
    • 設備需要採購、製作
    • 手機需要外接設備(透過micro USB / lightning / ipad 30pin)
    • 頻寬較少,僅適合傳輸文字訊息
    Clement ChenZigbee設備很便宜,也支援尋找附近鄰點的功能,但使用頻帶接近WiFi,很容易被WiFi干擾,要想辦法加入重傳功能或利用其他介面傳送。

 

    小俞YU介面設計

小俞YU小俞:報名UI設計!

佩承 劉歡迎 感謝Q口Q

    Mosi Wang改成緊急事件回報 用途比較廣XD

MOSI W

 

    Mosi Wang

 

小俞YU小俞:剛剛快速作了一些東西,有任何建議直接寫上來吧,其實因為現在flow還沒出來所以都亂做XDD(對了,名稱是亂取的)準備出門去守夜了掰!

    小俞Yu現場有網路XD
    小俞Yu我都收不到耶?是g0v的嗎?
    Mosi Wang青島東路的話 小七附近應該有 濟南的話應該很多隻啊我記得 (不過我只有用過g0v內部用的 沒用過開放給大家用的版本orz) 濟南路叫做 g0v-public 的樣子 開wifi搜尋一下
    小俞Yu那邊感覺完全被屏蔽啊QQ 中華電信工會你們不是要出來反對了嗎?快開個訊號車來嘛~
    Mosi Wang人太多 3g 沒訊號正常啦 而且我還真的沒看到中華的車耶 遠傳跟台哥大很多台XD
    小俞Yu我有看過一次神奇的車子,有拍到,照片再此:https://flic.kr/p/mrS8L5
    小俞Yu但其實不知道幹嘛用的就是了....感覺是私用(?)
    Mosi Wang那是小台基地台XD 用吉普車是方便颱風啊什麼時候進山裡面用的.... 那台車可以游泳的~~~
    佩承 劉已感動QQ
    佩承 劉clement是ptt的sibaseman大嗎? yes
      佩承 劉謝謝你!需要高手qq
      佩承 劉安安各位,結果3G網路可以通w
    小俞Yu那是否需要把醫療事件獨立出來?
    楊佑仁我覺得小俞 + MOSI W 的圖給出了一個開發方向,Firechat 提供了無差別發言平台,但無法針對某項訊息進行回應
    楊佑仁可以就 bbs 或論壇的形式製作,例如:
    楊佑仁1 . 依 GPS 標出事件地點
    楊佑仁2. 事件狀態粗分『待處理』『處理中』『處理中,待增援』『已解決』等等
    楊佑仁3. 一個事件底下包含內容、時間(系統產生)、地點(系統產生)、回應(依距離分出其可信度和有效性,也可用來做排序)
    楊佑仁4. 事件的產生和回應,可以用通用選項方式,加速回應速度,畢竟手持 device 的輸入速度仍舊快不過點選方式
    小俞Yu是否結合Google地圖?
    楊佑仁以上面的想法 Google Maps 是一定要的,但也需要提供依距離、狀態可進行排序、分類的列表(for offline device)
    小俞Yu誰來判事件狀態的處理進度?
    楊佑仁最簡單的方式當然是由事件發起人決斷,但如果遇到事件發起人被載去野放,可由現場人員發出最新狀態,但須列出該狀態發出筆數,每人限發一種狀態,並會取代同一事件同一人前一次狀態
    楊佑仁例如:[待處理]小七前有人昏倒,此事件因為發起人被野放無法即時更新狀態,現場人員即可發出狀態『[待處理(主)][處理中(3)][處理中,待增援(10)][已解決(0)]小七前有人昏倒』,從狀態中可看出大部分人認為仍須處理並增援
    楊佑仁現場人員的定義同樣可用距離決定
    小俞Yu所以可能可以用人數來判斷事件可信度(處理度),然後顯示出來高中低這樣。
    Clement Chen是否需要一個server去蒐集這些information(如GPS定位點與統計人數等等)後統整? 另外事件選項也是盡量簡化,如醫療、警備、衝突(攻擊行為)、社會安全或其他等等
    楊佑仁server 端要做的幾件事:
    楊佑仁1. 開發 API 供 APP 在進入網路環境中進行資料交換
    楊佑仁2. 能承受大量資料存取的儲存架構
    楊佑仁3. 資料統計與呈現頁面(討論是否需要管理介面,由誰管理?
    楊日新我想到bitcoin的網路架構,而且bitcoin中的區塊鏈不用全都儲存。
    楊佑仁如果能解決資料龐大的問題,我也投 的網路架構一票

 

 

再丟個圖給大家討論發想!!

    楊佑仁建議,將鴿子動態改成政府單位動態,應用範圍會較廣,因為你不能保證不會動用軍方武力(大誤
    楊佑仁可以談談訊號偵測的用意嗎?
    楊佑仁看看適不適合,可以加 profile settings 在搜尋戰友時可以依技能、種族...喔不,是職業分類
    小俞Yu訊號偵測是因為前一張圖有出現「目前頻道」與「連接節點」,我想也許可以用上
    小俞Yu而關於使用者,是否要用到這麼個人化?我以為只是會給一個隨機固定的UID(?)就可以開始使用了,這樣也能避免被國安單位監控。
    小俞Yu呃,新的圖怎麼又不見了= =
    楊佑仁profile settings 只是要讓個人的專長職業有地方填寫而已,當然,這東西有沒有必要就和大家討論一下囉

 

    小俞Yu話說,雖然主戰場準備撤退,但按照大夥對「執政當局」的理解,這個APP總有一天會派上用場的,所以我個人建議把他做完。
    Vendetta:emoji_1f44d:
    Chang Amy Yu-Tzu同意
    小俞Yu而且如果個人預測沒錯,最慢78月要簽貨貿的時候就有機會用到了…(唉…)
    小俞Yu同意+1

 

 

用了類似PTT的方式去做,不知道各位覺得如何?

    Mosi Wang還是要加排序方式給user選比較好~
    小俞Yu額,對耶,而且我發現忘了放時間…

 

*舊的過程圖檔自行清除了

詢求各位意見~