引用:
|
作者xx123
台北這麼大 . 人這麼多 . 地震預警沒收到者眾 ..... 莫不不會有這麼多人罵
撇除收訊不良場所 . 到底是地震預警系統本身架構失當人為錯誤 . 還是如您論的Ack確認的問題 ??
|
鵝不清楚您對Internet熟不熟,在此借用一下TCP/IP的原理說明一下了....
一般說TCP用於可靠性傳輸,TCP可靠的原因是其有flow control/error detection機制,sender在沒有收到recipient對某個data segment的Ack時會試著重送給recipient(i.e.Retry),直到recipient確認或timeout為止,在此Ack/Retry很明顯是跟個別recipient相關的,所以TCP無法做到sender送一次資料就能給一個以上的recipient(i.e.廣播或群播)....
而UDP是沒有flow control/error detection的,sender只負責往destination丟,因為沒有flow control/error detection,sender丟到一般unicast address就是單播,如果Dst是Class D(224/4)就是群播(IP Multicast,Internet實際上是沒有一般人認知的廣播的),如果是群播的話也無法做到by recipient的Ack的(原因如前述,有n個recipient時,是要以誰的Ack為準
)....
無線緊急警報或許可以用IP Multicast描述(雖然不太恰當),sender(主管機關)送出到電信業者端,電信業者經由其內部網路轉送到要告警區域的基地台,再由基地台經由無線傳輸段轉發給所有向其註冊的手機(以基地台為單位發送,而不是按門號發送
),壞就壞在基地台和手機間的無線傳輸段是個很不可靠的媒介,而以群播方式發送先天上又無法透過Ack/retry機制來確保可靠度,那就意味著這玩意就只能是best effort了
....
鵝拉拉雜雜寫了一坨,只是試著以技術的觀點描述這玩意為何先天上就是不可靠的,不依靠Ack才能在短時間內發送給盡可能多的受眾,如果要求可靠度的話就只能依靠Ack做error detection/correction,但在電信網路上就相當於只能按門號依次發送,不過真這麼幹又無法滿足這類time critical application的要求,您參考參考吧
....