cctg: protocol

顯示具有 protocol 標籤的文章。顯示所有文章

2024/9/30

RTSP

RTSP是1996年由 RealNetworks, Netscape, 哥倫比亞大學開發，提交草案給 IETF，1998年發布為 RFC2326，2016年RTSP 2.0 發布於 RFC 7826。RTSP 是串流媒體伺服器的控制協定，可建立與控制終端設備跟伺服器之間的多媒體 session。

RTSP 協定本身看起來跟 HTTP 類似，但 HTTP 本身是 stateless，而RTSP 是 stateful，故需要追蹤 session。RTSP 是用 TCP 連線，而多媒體本身，是用 RTP 傳輸，可以用 TCP 或 UDP，常見狀況是為求傳輸速度快，使用 UDP。

節錄一個 RTSP client 取得 RTSP 的封包過程

Options

查詢 RTSP server 支援的 command

Client -> Server

Request: OPTIONS rtsp://192.168.1.11:8554/mystream RTSP/1.0\r\n
CSeq: 2\r\n
User-Agent: LibVLC/3.0.20 (LIVE555 Streaming Media v2016.11.28)\r\n
\r\n

Server -> Client

Response: RTSP/1.0 200 OK\r\n
CSeq: 2\r\n
Public: DESCRIBE, ANNOUNCE, SETUP, PLAY, RECORD, PAUSE, GET_PARAMETER, TEARDOWN\r\n
Server: gortsplib\r\n
\r\n

Describe

查詢可處理的多媒體資料格式，server 以 SDP 方式回覆

Client -> Server

Request: DESCRIBE rtsp://192.168.1.11:8554/mystream RTSP/1.0\r\n
CSeq: 3\r\n
User-Agent: LibVLC/3.0.20 (LIVE555 Streaming Media v2016.11.28)\r\n
Accept: application/sdp\r\n
\r\n

Server -> Client

Response: RTSP/1.0 200 OK\r\n
CSeq: 3\r\n
Content-Base: rtsp://192.168.1.11:8554/mystream/\r\n
Content-length: 560
Content-type: application/sdp
Server: gortsplib\r\n
\r\n
Session Description Protocol Version (v): 0
Owner/Creator, Session Id (o): - 0 0 IN IP4 127.0.0.1
Session Name (s): test
Connection Information (c): IN IP4 0.0.0.0
Time Description, active time (t): 0 0
Media Description, name and address (m): video 0 RTP/AVP 96
Media Attribute (a): control:rtsp://192.168.1.11:8554/mystream/trackID=0
Media Attribute (a): rtpmap:96 H264/90000
Media Attribute (a): fmtp:96 packetization-mode=1; profile-level-id=640032; sprop-parameter-sets=Z2QAMqzIUB4AiflwEQAAAwPpAAC7gA8YMZY=,aOk4XLIs
Media Description, name and address (m): audio 0 RTP/AVP 97
Media Attribute (a): control:rtsp://192.168.1.11:8554/mystream/trackID=1
Media Attribute (a): rtpmap:97 mpeg4-generic/48000/2
Media Attribute (a): fmtp:97 config=1190; indexdeltalength=3; indexlength=3; mode=AAC-hbr; profile-level-id=1; sizelength=13; streamtype=5

Setup

要求 server 設定傳送某一個 media stream，setup 要在 play 之前完成

Client -> Server

Request: SETUP rtsp://192.168.1.11:8554/mystream/trackID=0 RTSP/1.0\r\n
CSeq: 4\r\n
User-Agent: LibVLC/3.0.20 (LIVE555 Streaming Media v2016.11.28)\r\n
Transport: RTP/AVP/TCP;unicast;interleaved=0-1
\r\n

Server -> Client

Response: RTSP/1.0 200 OK\r\n
CSeq: 4\r\n
Server: gortsplib\r\n
Session: 262553a7d5084e8fb57f9d8f485c89f4
Transport: RTP/AVP/TCP;unicast;interleaved=0-1;ssrc=03DAD41B
\r\n

Setup

client 透過 setup 跟 server 確認 stream session

Client -> Server

Request: SETUP rtsp://192.168.1.11:8554/mystream/trackID=1 RTSP/1.0\r\n
CSeq: 5\r\n
User-Agent: LibVLC/3.0.20 (LIVE555 Streaming Media v2016.11.28)\r\n
Transport: RTP/AVP/TCP;unicast;interleaved=2-3
Session: 262553a7d5084e8fb57f9d8f485c89f4
\r\n

Server -> Client

Response: RTSP/1.0 200 OK\r\n
CSeq: 5\r\n
Server: gortsplib\r\n
Session: 262553a7d5084e8fb57f9d8f485c89f4
Transport: RTP/AVP/TCP;unicast;interleaved=2-3;ssrc=294122AE
\r\n

Play

在 setup 設定的 session 裡面，開始播放 media

Client -> Server

Request: PLAY rtsp://192.168.1.11:8554/mystream/ RTSP/1.0\r\n
CSeq: 6\r\n
User-Agent: LibVLC/3.0.20 (LIVE555 Streaming Media v2016.11.28)\r\n
Session: 262553a7d5084e8fb57f9d8f485c89f4
Range: npt=0.000-\r\n
\r\n

Server -> Client

Response: RTSP/1.0 200 OK\r\n
CSeq: 6\r\n
RTP-Info: url=rtsp://192.168.1.11:8554/mystream/trackID=0;seq=10453;rtptime=1024864644,url=rtsp://192.168.1.11:8554/mystream/trackID=1;seq=4824;rtptime=3779844790\r\n
Server: gortsplib\r\n
Session: 262553a7d5084e8fb57f9d8f485c89f4
\r\n

RTP

用 RTP 的格式，傳送 media 內容

Server -> Client

10.. .... = Version: RFC 1889 Version (2)
..0. .... = Padding: False
...0 .... = Extension: False
.... 0000 = Contributing source identifiers count: 0
0... .... = Marker: False
Payload type: DynamicRTP-Type-96 (96)
Sequence number: 10453
Timestamp: 1024871144
Synchronization Source identifier: 0x03dad41b (64672795)
Payload: 09f0

Teardown

client 通知 server 停止播放 media

Client -> Server

Request: TEARDOWN rtsp://192.168.1.11:8554/mystream/ RTSP/1.0\r\n
CSeq: 7\r\n
User-Agent: LibVLC/3.0.20 (LIVE555 Streaming Media v2016.11.28)\r\n
Session: 262553a7d5084e8fb57f9d8f485c89f4
\r\n

References

即時串流協定 - 維基百科，自由的百科全書

2024/9/23

Secure Reliable Transport (SRT)

Secure Reliable Transport (SRT) 是開放的 video transport protocol，由 Halvision 提出，目的是要提供一個加密、低延遲的視訊串流傳輸協定，過去比較常見的協定是 RTMP, RTSP, HLS, WebRTC。SRT 是在 2013 年由 Haivision 發表，後來 Haivision 在 2017 年將 protocol 開放，交給 SRT Alliance，然後慢慢有更多廠商支援這個協定。

在這麼長久的網路視訊串流發展歷史中，RTMP 常見於網路影片直播，尤其是行動網路的直播，RTSP 常見於網路攝影機。RTMP 是以 TCP 為基礎，因為發展當時的網路頻寬不大，必須要用 TCP 本身的連線穩定度，封包傳送機制，來確保網路直播的可用性。

SRT 則是完全使用 UDP，在 Haivision 的文件中，提出 SRT 的延遲比 RTMP 少 2.5~3.2 倍。SRT 跟 RTP 的差異是，SRT 借鑒了 RTMP 控制機制，傳輸中除了 video 資料封包，還有控制封包，控制封包可根據網路延遲及品質，動態調整發送端的 video 發送速度，也能有限制地決定要不要重傳遺失的封包。

SRT 可套用加密機制，使用最常見的 AES-128/256 加密方法。

SRT 只是一種影片切割與包裝的方法，因此能適用於任何一種影片 codec。

Server

GitHub - Edward-Wu/srt-live-server: srt live server for low latency 這是一個 SRT streaming server。

安裝前，必須要先安裝 GitHub - Haivision/srt: Secure, Reliable, Transport SRT library，我們在 CentOS 測試，根據這個文件說明，依照以下步驟安裝

sudo yum install tcl pkgconfig openssl-devel cmake gcc gcc-c++ make automake
./configure
make
make install

安裝 SRT library 後，可安裝 server，下載 srt-live-server-master.zip，解壓縮後，直接 make 即可

sudo make

執行

cd bin
./sls -c ../sls.conf

Client

測試 SRT 可使用 OBS Studio

發布的網址為

srt://192.168.1.11:8080?streamid=uplive.sls.com/live/test

接收部分，可用 VLC video player 測試，網址為

srt://192.168.1.11:8080?streamid=live.sls.com/live/test

實際上實測，OBS 發佈到 VLC 接收，大約有 4~5 秒的延遲

iOS app

可安裝 Haivision Play Pro - Haivision iOS APP，這個 app 也可以接收 SRT streaming

設定方式如下

References

什麼是SRT 安全可靠傳輸協議

Secure Reliable Transport - Wikipedia

【ProAV Lab】SRT，互聯網上的最佳視訊串流協定 | Lumens

RTMP vs. SRT: Comparing Latency and Maximum Bandwidth - Haivision

2024/9/9

InfiniBand IB

作為網路互連的技術方案，Ethernet 跟 InfiniBand (IB) 兩者的發展目標不同，導致現在應用的領域跟範圍都不同。

使用場景

一般人比較常聽到 Ethernet，Ethernet 用在區域網路中，可將多個網路設備連接起來，以光纖連接 Internet，以無線網路連接手持設備。InfiniteBand 主要用在HPC 與 data center，這類對高頻寬低延遲的網路連接需求較高的應用場景

頻寬

Ethernet 的應用發展，並不是以高速頻寬為主要發展的重點，他的重點在讓多種異質網路終端能夠互相連接起來，所以頻寬並不是發展的重點。通常 Ethernet 是在 1Gbps 到 100 Gbps，而InfiniBand 可到 100 Gbps 或 200 Gbps，像這份報導的說明，InfiniBand進入400Gb/s世代，Nvidia新款網路交換器揭開序幕 | iThome 已經到了 400Gbps 的時代。

應用範圍

Ethneret 面向一般終端的消費者，用來做個人使用的資料傳輸並連接 Internet。InfiniBand 是用在大量的資料運算，在現在最熱門的 AI 時代，要建構一個 AI cluster，會使用 InfiniBand 作為 cluster 節點的連接技術。

InfiniBand 另一個應用是在超級電腦裡面，因為超級電腦叢集也需要這種高速低延遲的資料傳輸。

成本

InfiniBnad 的效能高，相對成本就很高，沒有特殊的需求，一般是不會使用 InfiniBand

網路模式

InfiniBand 比 Ethernet 容易管理，每一個 end node 會透過一個 layer 2 switch 配置網路節點 ID，再往上以 Router 統計計算網路資料轉發路徑。

Ethernet 是用硬體的 MAC 網路模式，往上使用 IP 搭配 ARP 建構網路，且網路本身沒有學習機制，容易產生環狀網路，這又要透過 STP 協定解決，增加了網路的複雜度

Socket Direct Protocol (SDP)

Trail: Sockets Direct Protocol (The Java™ Tutorials)

Java 7 Sockets Direct Protocol – Write Once, Run Everywhere …. and Run (Some Places) Blazingly - InfoQ

SDP

在 JDK 7 裡面，就提供了一種不同於 TCP/IP 傳統的 Socket 網路的 Socket Direct Protocol，SDP 能夠透過 InifiBand 的 Remote Direct Memory Access (RDMA) ，以低延遲的方法，不透過 OS，遠端存取其他電腦的記憶體。

透過這張圖的說明，可以了解為什麼 SDP 能夠提供高速的通訊，傳統的 TCP/IP 需要一層一層接過 Application Layer -> Transport Layer -> Network Layer -> Physical Layer，SDP 則是從 Application 一步直接穿到 RDMA enabled channel adapter card

參考這個連結的圖片: SDP

References

InfiniBand - 維基百科，自由的百科全書

InfiniBand與以太網：它們是什麼？ | 飛速（FS）社區

InfiniBand之技術架構介紹

2024/8/12

STOMP

Simple (or Streaming) Text Oriented Message Protocol (STOMP) 是一種單純的以純文字為基礎的協定，通常用在訊息導向的 client-server 互動的訊息交換標準，所以會在 Message Queue 以及 WebSocket 看到使用這個 Protocol 傳遞訊息。

Commands

STOMP 類似 HTTP protocol，在 client 傳送給 server 定義了以下這些 Commands

CONNECT
SEND
SUBSCRIBE
UNSUBSCRIBE
BEGIN
COMMIT
ABORT
ACK
NACK
DISCONNECT

在 Server 傳送給 client 定義了以下的 commands

CONNECTED
MESSAGE
RECEIPT
ERROR

在規格中，稱呼每一則傳遞的訊息為 frame，frame 的第一行都是 command，後面跟著多行 key:value 的 headers，然後有一行空白，最後面是 body content，這樣的訊息格式跟 http 完全一樣

frame 結束時，要有一個 NULL octet，在規格文件標記為 ^@

只有 SEND, MESSAG, ERROR 這三個 frame 能夠有 body，其他 frames 不能有 body

Headers

commands 跟 headers 必須使用 UTF-8 encoding，在 parsing header 時，必須要做這樣的轉換

\r (0x5C, 0x72) 要轉換為 carriage return (0x0D)
\n (0x5C, 0x6E) 要轉換為 line feed (0x0A)
\c (0x5C, 0x63) 要轉換為 : (0x3A)
\\ (0x5C, 0x5C) 要轉換為 \ (0x5C)

在 header 的部分，除了因應自己的需求，要定義的 headers 以外，建議要定義這些標準的 header

content-length
content-type

這兩個 headers 類似 http protocol，就是整個 frame 的長度，以及 content 的內容格式

為避免惡意的 client，故意傳送非常大的 frame，把 server 的訊息 buffer 撐爆，server 可以限制以下這些部分的長度

單一 frame 裡面可使用的 header 數量
每一行 header 的最大長度
frame body 的最大長度

在 Spec 裡面，將 frame 區分為 Connecting, Client, Server 三個部分

Connecting

client 連線時，要發送 CONNECT

CONNECT
accept-version:1.2
host:stomp.github.org

^@

連線也可加上其他 headers，例如 login 帳號，passcode 密碼，heart-beat

server 接受連線要回應

CONNECTED
version:1.2

^@

還可以加上 session 代表 session id，server 代表 server name

CONNECT
accept-version:1.0,1.1,2.0
host:stomp.github.org

^@

完全不接受連線，就回應ERROR，這樣是說明 client 版本不符

ERROR
version:1.2,2.1
content-type:text/plain

Supported protocol versions are 1.2 2.1^@

Heart-beating

因為 TCP 連線有可能因為太久沒有資料通過，該連線通道有可能會被網路中兼任一個節點關閉，heart-beating 功能，類似 ping pong，定時發送，維持 TCP 連線。

heart-beat header 格式有兩個正整數，用逗號隔開

第一個正整數代表 sender 的 outgoing heart-beat

0: 表示無法發送 heart-beat
其他: 代表該 sender 保證在多少 milliseconds 之間，可發送 heart-beat

第二個正整數代表 sender 期待收到的 heart-beat

0: 表示不需要接收 heart-beat
其他: 代表該 sender 希望在多少 milliseconds 之間，可收到 heart-beat

CONNECT
heart-beat:<cx>,<cy>

CONNECTED
heart-beat:<sx>,<sy>

Client Frames

SEND
SUBSCRIBE
UNSUBSCRIBE
BEGIN
COMMIT
ABORT
ACK
NACK
DISCONNECT

SEND

send message to a destination

SEND
destination:/queue/a
content-type:text/plain

hello queue a
^@

註冊要 listen to a given destination

SUBSCRIBE
id:0
destination:/queue/foo
ack:client

^@

UNSUBSCRIBE

UNSUBSCRIBE
id:0

^@

ACK

acknowledge 確認收到某個訊息，如果有 transaction header，代表這個 ACK 是某個 transaction 的一部分

ACK
id:12345
transaction:tx1

^@

NACK

ACK 的相反

BEGIN

開始某個 transaction

BEGIN
transaction:tx1

^@

COMMIT

commit transaction

COMMIT
transaction:tx1

^@

ABORT

roll back a transaction

ABORT
transaction:tx1

^@

DISCONNECT

client 在關閉 TCP connection 之前，發送 DISCONNECT，正式通知 server 要關閉連線

client

DISCONNECT
receipt:77
^@

server response

RECEIPT
receipt-id:77
^@

client 在收到 RECEIPT 後，才正式關閉連線

Server Frames

MESSAGE
RECEIPT
ERROR

MESSAGE

傳送訊息給 destination，一定要加上 message-id header

MESSAGE
subscription:0
message-id:007
destination:/queue/a
content-type:text/plain

hello queue a^@

RECEIPT

server 確認有收到 client 發送的某一個 FRAME

RECEIPT
receipt-id:message-12345

^@

ERROR

錯誤發生時，server 發送給 client

ERROR
receipt-id:message-12345
content-type:text/plain
content-length:170
message:malformed frame received

The message:
-----
MESSAGE
destined:/queue/a
receipt:message-12345

Hello queue a!
-----
Did not contain a destination header, which is REQUIRED
for message propagation.
^@

Frames and Headers

除了上面提到，標準的 headers: content-length, content-type, receipt，所有 frames 建議必要使用與選擇性使用的 headers 如下

CONNECT or STOMP
- REQUIRED: accept-version, host
- OPTIONAL: login, passcode, heart-beat
CONNECTED
- REQUIRED: version
- OPTIONAL: session, server, heart-beat
SEND
- REQUIRED: destination
- OPTIONAL: transaction
SUBSCRIBE
- REQUIRED: destination, id
- OPTIONAL: ack
UNSUBSCRIBE
- REQUIRED: id
- OPTIONAL: none
ACK or NACK
- REQUIRED: id
- OPTIONAL: transaction
BEGIN or COMMIT or ABORT
- REQUIRED: transaction
- OPTIONAL: none
DISCONNECT
- REQUIRED: none
- OPTIONAL: receipt
MESSAGE
- REQUIRED: destination, message-id, subscription
- OPTIONAL: ack
RECEIPT
- REQUIRED: receipt-id
- OPTIONAL: none
ERROR
- REQUIRED: none
- OPTIONAL: message

雖然規格有提到這些 header 建議，但實際上，這份規格比較接近是針對 messaging system 的 frame 建議。

常常會看到的是只使用了類似 http frame 的格式，每一則傳遞的訊息為 frame，frame 的第一行都是 command，後面跟著多行 key:value 的 headers，然後有一行空白，最後面是 body content，就只有符合這樣的使用規則，其他部分的內容，都是讓 application 自己決定該怎麼使用。

header, body 的內容，都是讓 application 自己決定自己的 client-server 溝通的 protocol 訊息內容。

References

STOMP

Streaming Text Oriented Messaging Protocol - Wikipedia

STOMP Protocol - GeeksforGeeks

2023/12/4

TSN (Time-Sensitive Networking)

時效性網路(Time-sensitive Networking, TSN)是電機電子工程師協會(IEEE)定義的專用於使乙太網路更具確定性的一種網路拓展。TSN 是區域網路(LAN)解決方案，只有在TSN LAN內部才能保證其即時性。

為解決乙太網路低延遲與時間同步的問題，Industrial Ethernet 的 Protocol

EtherCAT
EtherNet/IP
PROFINET
Powerlink
Modbus-TCP
SERCOS Ⅲ

在應用上來說Industrial Ethernet是與Standard Ethernet不相容的。TSN 解決了這些問題

TSN相容於Standards Ethernet IEEE802.1規範，可以與非TSN乙太網路一起使用的區域網路，TSN支援更高頻寬的傳輸速度 (Gbit/s以上)
TSN工作在Layer 2 technology of OSI model
在Standards Ethernet的區域網路中可以做到：
高頻寬、低延遲、保障頻寬(Priority)、時間同步等功能
透過IEEE 802.1AS (協議簡稱精確時鐘協議Precision Timing Protocol - PTP) 實現TSN裝置之間共享時間戳記 (Time Stamping) 的設備。

TSN 並未取代 Layer 2 以上層級的協定，也未定義軟體介面或硬體配置與特點，因此可相容於多種應用程式開發介面 (API)

TSN主要功能是時間同步 (Time Sync)、優先權 (Priority)、可靠性 (Reliability)、資源管理 (Resource Management)。時間同步 (Time Sync) 是透過802.1AS標準，在傳送跟接收的封包上加上時間戳記 (Time Stamping)，在區域網路之中可以將設備之間的訊號同步在微秒 (us) 範圍

優先權 (Priority) 是透過802.1Qbu & 802.1Qbv標準，允許將正在傳輸的資料中斷讓優先等級較高的資料進行傳送，等優先等級較高的資料傳送完成後再回到先前被中斷的資料繼續傳輸，確保優先等級較高的資料有最大的傳輸頻寬跟最低的傳輸延遲時間。

可靠性 (Reliability) 是透過802.1CB標準，將原本要傳送的封包複製成多個不同封包，每一個不同的封包會透過不同的路徑來做傳送，最後在接收端會自動消除其它的冗餘 (Redundancy) 封包，使其接收端只會收到一筆封包資料，即使在傳輸路經之中出現了單點的故障情況 (如設備損壞或是電纜線斷開等)，都可以確保目的端可以接收到正確且完整的資料。

資源管理(Resource Management) 是透過802.1Qcc標準，將TSN配置分成三種模式：

完全分散模式(Fully Distributed Model)
完全集中模式(Fully Centralized Model)
集中&分散混合模式(Centralized & Distributed Model)

一些關鍵的 IEEE 802.1 TSN 子標準包括：

IEEE 802.1 AS – 時序與同步
IEEE 802.1Qbv – 時間感知塑形器
IEEE 802.3Qbr – 散佈快速流量
IEEE 802.1Qbu – 訊框搶佔
IEEE 802.1Qca – 路徑控制與保留
IEEE 802.1CB – 備援
IEEE 802.1 Qcc – 串流保留的增強與改善
IEEE 802.1 Qch – 迴圈佇列與轉送
IEEE 802.1Qci – 逐一串流過濾與監管
IEEE 802.1CM – 前傳網路的時效性網路

TSN的應用

影音設備

電影院、音樂廳控制系統，聲音從表演者經過傳輸到聽眾接收，中間如果有延遲，是很難被接受的

汽車控制

汽車控制系統裡面有四個主流的匯流排構成 LIN、CAN、FlexRay & MOST，不同系統採用不同的匯流排且涉及到相當複雜的佈線，汽車上的設計以及感知器會日趨複雜，連接的設備也愈來愈多，TSN的技術可以區分時間敏感度以及優先層級的資料，降低延遲以及時間同步等優點，系統就能輕易且正確傳送從感測器到到影音串流各種不同類型的資料，進而提供可靠性以及可預測性的高速網路系統。

工業應用

感測器連接的節點愈多，想要每個感測器跟控制器的無縫連接就愈困難，工業自動化中，精準的時間是關鍵要素，傳統的乙太網路並無法保證網路延遲範圍，透過TSN的網路環境，在傳統乙太網路上加入了即時性的控管，對網路流量進行優先排序，提供保證延遲範圍，以便對時間較敏感的資料可以在正確的時間傳到正確的目標端。

References

一讀就懂的TSN (Time-Sensitive Networking) 應用與架構 | Macnica Galaxy

時間敏感網路（TSN）中央控制器簡介 - 科技新知 - 產業學習網

## TSN 讓工業物聯網和工業 4.0 發揮更大效用 — 您不可不知的 5 件事

TSN技術說明與Avnu認證流程 | 百佳泰 Allion Labs

# 如何實作時效性網路以確保確定性通訊

保障時遲性/高傳輸速率　時效性網路掀工業自動化革命 | 新通訊

2023/10/23

Chicken-or-Egg Problem in Network

在網路效應中，常見到 2-sided martketplace，nfx 提出 19 個策略，用來解決先有雞還是先有蛋的問題。

Get the hardest side first

比較困難的那一邊，也代表其網路價值比較高

ex: Ourdoorsy 是 RV 租借市場，困難點在於如何吸引 RV owners
Appeal tightly to a niche and repeat

找到市場的痛點

ex: eBay 一開始 Beanie Babies。Craigslist 一開始是Craig的朋友想要找公寓，找工作
Subsidize the most valuable side of the market

付費補貼給該網路中最有價值的一方，請他們加入網路

ex: Uber 付費給司機
Make the supply look bigger with automation

從 supply-side 收集資料，進而讓該活動被注意(產生光環)

ex: Yelp 在平台收集評論資料
Buid one side as an email list

這是一個啟動 martketplace 最簡單的方法，特別是 buyer 同時也是 sellers 的狀況

ex: Craigslist
Host meetups & gatherings 辦聚會

舉辦社交活動，可得到客戶直接的反饋

ex: Poshmark 舉辦 "Posh Parties" 讓客人交換時尚資訊
Buid a SaaS tool for one side of the market

為某一方建立 SaaS 工具，這樣就能吸引另一方

ex: OpenTable 為餐廳建立預訂軟體服務
Give software to a thrid party who bring you one side of the market

提供軟體給第三方

ex: Android 為手機製造商提供軟體，手機可帶來消費者需求
Find one giant user for the initial supply or demand

一開始先找一個大客戶

ex: Candex 提供軟體給 Siemens 使用
Only make one side to change their behavior

讓某一方改變行為

ex: Square 改變店家行為，最終讓消費者也使用他們的信用卡
Make something free suddenly

把原本要付費的東西，突然變成免費，吸引客戶

ex: Robinhood 免費交易。Skype 讓電話免費。Napster 讓音樂免費。
Buid a product first, then open a marketplace

先做產品，再打開市場

ex: Salesforce 建立線上 CRM 工具
Connect the two sides by hand

先以人工(代工)方式連接兩端

ex: Zappos 早期處理網路訂單，是以人工去買鞋，然後送貨完成
Favor markets where buyers are sellers,too

先做 buyers 也是 sellers 的市場

ex: Poshmark 使用者買衣服，也會賣衣服
Create exclusive access

建立獨佔式存取，該想法可產生病毒式行銷

ex: Gmail, clubhouse
Set a geographic constraint

設定地理限制，在初期先限制在某些地方發布服務

ex: Lyft, Yelp, Craigslist
Set a time constraint

設定時間限制，初期只在某些時間提供服務

ex: Tophatter 只提供在 8-9pm 可作競標
Set a demand constraint

設定需求限制

ex: Groupon 限制店家每天產生一個 groupon
Pay users with tokens

以代幣支付給使用者，為市場創造代幣，提供代幣給使用者

References

19 Tactics to Solve the Chicken-or-Egg Problem and Grow Your Marketplace

2023/10/16

網路效應

nfx.com 有一份 The Network Effects Bible 討論網路效應的重要性，每增加一個使用者，會讓這個產品/服務更有價值，也就是大者恆大的局面，在網路時代，所有系統發展的初期，都還是在獲取使用者的眼球的競爭下，只有大量的使用者，才算是拿到了入場門票，才會有下一個維持跟進化的問題。

數學模型

有幾個網路效應的法則，試圖以數學模型說明網路效應的價值

Sarnoff’s Law

早期的電視廣播，其價值直接跟使用者數量成正比。該網路都是從網路中心單向發送連結到使用者
```
V = N
```
Metcalfe’s Law

在 Internet 時代，連上網路的電腦都可以用任何方式互相傳送資訊。因此網路的價值每增加一個 node，該 node 都可以跟原本的其他 node 連結，價值應該要是所有的節點數量。
```
V = N * (N-1) /2 => 約等於 N^2
```
Reed’s Law

David P. Reed 於 1999 年提出，增加一個 node 的網路價值，除了連結的節點數量以外，還要再乘上該 node 帶來的潛在的 cluster，該 node 還會產生更多 sub-groups/clusters
```
V = 2^N
```

網路特徵

不規則性

nodes 與 cluster 的分佈並不均勻，各節點之間的 link 狀況，也跟真實世界一樣，沒有固定的樣式
身份：真實、假名、匿名

有真實身份的網路，會比假名的網路能更有效地建構網路。但在加密或間諜應用中，反而需要匿名的網路，但卻可能因為匿名，該網路關係更容易被破壞。
不對稱性

有不同的角色組合的網路，且某一邊的使用者取得比其他的困難。這被稱為是 Demand-Side 或是 Supply-Side Marketplace，例如 Uber
同質、異質網路

當所有 nodes 的角色都一樣時，這是同質網路，如果網路內有分不同的角色，則是異質網路，例如網拍網站，有分買家及賣家兩種角色。
漸近 Asymptotic

通常使用者增加，每個使用者產生的價值也在增加，但當網路成長到某個程度後，網路效應的增加就開始減弱。ex: Uber 乘客的等待時間，隨著司機數量增加到某個程度後，等待時間就無法再一直縮短了
同邊 Same-Side

同樣使用 Windows Office 的使用者，因為檔案相容性的關係，會因為使用者增加而讓該檔案更加流通
橫向 Cross-Side

例如 Uber，driver 增加會增加客人，客人增加也會再吸引更多 driver
Indirect

例如 ebay，新賣家的加入，只會讓賣家之間的競爭更激烈，但由於賣家增加，更吸引買家加入，整體來說，還是會讓所有賣家間接受惠。
Negative

網路的負面效應有兩種：Congestion (增加使用量) 及 Pollution (增加規模)

因為更多人使用網路，會讓網路壅塞，速度變慢。

FB, Twitter 會因為更多人使用，而污染自己個人的 News Feed

建構與維護

Multiplayer vs. Single-Player Mode

單人模式只會線性增長，多人的聯網產品同時具有單人與多人的價值
轉換成本 switching cost

切換到不相容的產品，會花時間、精神與金錢，這會讓使用者傾向於使用同一個廠商的商品，並待在同一個生態體系下
Chicken or Egg Problem (Cold Start Problem)

這是 2-sided martketplace 常見的問題，buyers/sellers 或是 developers/users

當有一邊的使用者增加，才會讓另一邊也加入。有 19 Tactics to Solve the Chicken-or-Egg Problem and Grow Your Marketplace 能解決此問題
Multi-Tenanting

同時加入多個互相競爭的網路 ex: Lyft, Uber，同時加入多個社交平台

越大的網路會越有知名度，越能吸引新客戶
Disintermediation 去中心化

在 marketplace 或 merket network 產品中很常見。一開始透過該網路進行交易，後續就改為不透過網路平台而直接交易。
Retention 留存率

客戶回頭再使用產品的頻率。留存率高的網路效應才高。

結語

經過這些年的社交網路更迭，有很明顯的世代交替狀況，使用者的增加，確實放大了網路的價值，也許大部分的人會因為要跟其他人溝通與交流，而加入某些網路，雖然人數增加了，卻也凸顯了沒有一個系統能夠適用於所有人的情況，系統可以瞬間爆紅，也可能會一下子就因為技術替換與世代交替消失。

References

# 网络效应“圣经”（上）：网络效应为什么重要？其运作原理是什么？

# 网络效应“圣经”（下）：如何建立和维护网络效应？相关概念有哪些？

《NFX：网络效应圣经》笔记

The Network Effects Manual: 16 Different Network Effects (and counting)

# 网络效应是什么？网络效应定律简介

2023/9/18

OAuth

傳統的 Client-Server 架構裡， Client 要拿取受保護的資源 (Protected Resoruce) 的時候，要向 Server 出示使用者 (Resource Owner) 的帳號密碼才行。如果要讓第三方應用程式也可以使用這些 Resources ，則需要 Resource Owner 把帳號密碼給這個第三方應用程式，這時候會產生以下的問題：

第三方應用程式必須以明碼儲存 Resource Owner 的帳號密碼
Server 要支援密碼認證
第三方應用程式會得到完整存取 Protected Resources 的權限，無法限制時效
Resource Owner 無法只撤回某一個第三方應用程式的存取權，必須要修改密碼才能撤回。
當某一個第三方應用程式被破解，就會導致使用該密碼的所有資料被破解。

OAuth 解決這些問題的方式，是引入一個認證層 (authorization layer) ，並把 client 跟 resource owner 的角色分開。Client 會先索取存取權，來存取 Resource Owner 擁有的資源，這些資源會放在 Resource Server 上面，並且 Client 會得到一組不同於 Resource Owner 所持有的認證碼，也就是 access token。

角色定義

Resource Owner

可授權別人去存取 Protected Resource。如果這個角色是人類的話，就是指使用者 (end-user)。
Resource Server

存放 Protected Resource 的伺服器，可以根據 Access Token 來接受使用 Protected Resource 的請求。
Client

讓 Resource Owner 授權後，可以去存取 Protected Resource 的應用程式。
Authorization Server

認證 Resource Owner 並獲得 Resource Owner 許可後，核發 Access Token 的伺服器。

+--------+                               +---------------+
|        |--(A)- Authorization Request ->|   Resource    |
|        |                               |     Owner     |
|        |<-(B)-- Authorization Grant ---|               |
|        |                               +---------------+
|        |
|        |                               +---------------+
|        |--(C)-- Authorization Grant -->| Authorization |
| Client |                               |     Server    |
|        |<-(D)----- Access Token -------|               |
|        |                               +---------------+
|        |
|        |                               +---------------+
|        |--(E)----- Access Token ------>|    Resource   |
|        |                               |     Server    |
|        |<-(F)--- Protected Resource ---|               |
+--------+                               +---------------+

Refresh Token 流程

+--------+                                           +---------------+
|        |--(A)------- Authorization Grant --------->|               |
|        |                                           |               |
|        |<-(B)----------- Access Token -------------|               |
|        |               & Refresh Token             |               |
|        |                                           |               |
|        |                            +----------+   |               |
|        |--(C)---- Access Token ---->|          |   |               |
|        |                            |          |   |               |
|        |<-(D)- Protected Resource --| Resource |   | Authorization |
| Client |                            |  Server  |   |     Server    |
|        |--(E)---- Access Token ---->|          |   |               |
|        |                            |          |   |               |
|        |<-(F)- Invalid Token Error -|          |   |               |
|        |                            +----------+   |               |
|        |                                           |               |
|        |--(G)----------- Refresh Token ----------->|               |
|        |                                           |               |
|        |<-(H)----------- Access Token -------------|               |
+--------+           & Optional Refresh Token        +---------------+

Grant Flow

Authorization Code Grant Type Flow

+----------+
| Resource |
|   Owner  |
|          |
+----------+
     ^
     |
    (B)
+----|-----+          Client Identifier      +---------------+
|         -+----(A)-- & Redirection URI ---->|               |
|  User-   |                                 | Authorization |
|  Agent  -+----(B)-- User authenticates --->|     Server    |
|          |                                 |               |
|         -+----(C)-- Authorization Code ---<|               |
+-|----|---+                                 +---------------+
  |    |                                         ^      v
 (A)  (C)                                        |      |
  |    |                                         |      |
  ^    v                                         |      |
+---------+                                      |      |
|         |>---(D)-- Authorization Code ---------'      |
|  Client |          & Redirection URI                  |
|         |                                             |
|         |<---(E)----- Access Token -------------------'
+---------+       (w/ Optional Refresh Token)

要向 Authorization Server 先取得 Grant Code 再取得 Access Token。
適合 Confidential Clients ，如部署在 Server 上面的應用程式。
可以核發 Refresh Token。
需要 User-Agent Redirection。

Implicit Grant Type Flow

+----------+
| Resource |
|  Owner   |
|          |
+----------+
     ^
     |
    (B)
+----|-----+          Client Identifier     +---------------+
|         -+----(A)-- & Redirection URI --->|               |
|  User-   |                                | Authorization |
|  Agent  -|----(B)-- User authenticates -->|     Server    |
|          |                                |               |
|          |<---(C)--- Redirection URI ----<|               |
|          |          with Access Token     +---------------+
|          |            in Fragment
|          |                                +---------------+
|          |----(D)--- Redirection URI ---->|   Web-Hosted  |
|          |          without Fragment      |     Client    |
|          |                                |    Resource   |
|     (F)  |<---(E)------- Script ---------<|               |
|          |                                +---------------+
+-|--------+
  |    |
 (A)  (G) Access Token
  |    |
  ^    v
+---------+
|         |
|  Client |
|         |
+---------+

Authorization Server 直接向 Client 核發 Access Token （一步）。
適合非常特定的 Public Clients ，例如跑在 Browser 裡面的應用程式。
Authorization Server 不必（也無法）驗證 Client 的身份。
禁止核發 Refresh Token。
需要 User-Agent Redirection。
有資料外洩風險。

Resource Owner Password Credentials Grant Type Flow

+----------+
| Resource |
|  Owner   |
|          |
+----------+
     v
     |    Resource Owner
    (A) Password Credentials
     |
     v
+---------+                                  +---------------+
|         |>--(B)---- Resource Owner ------->|               |
|         |         Password Credentials     | Authorization |
| Client  |                                  |     Server    |
|         |<--(C)---- Access Token ---------<|               |
|         |    (w/ Optional Refresh Token)   |               |
+---------+                                  +---------------+

Resource Owner 的帳號密碼直接拿來當做 Grant。
適用於 Resource Owner 高度信賴的 Client （像是 OS 內建的）或是官方應用程式。
其他流程不適用時才能用。
可以核發 Refresh Token。
沒有 User-Agent Redirection。

Client Credentials Grant Type Flow

+---------+                                  +---------------+
|         |                                  |               |
|         |>--(A)- Client Authentication --->| Authorization |
| Client  |                                  |     Server    |
|         |<--(B)---- Access Token ---------<|               |
|         |                                  |               |
+---------+                                  +---------------+

Client 的帳號與密碼直接用來 Grant
適用於跑在 Server 上面的 Confidential Client
不建議核發 Refresh Token
沒有 User-Agent Redirection

References

OAuth 2.0 筆記 (1) 世界觀

OAuth 2.0 筆記 (4.1) Authorization Code Grant Flow 細節

OAuth 2.0 筆記 (4.2) Implicit Grant Flow 細節

OAuth 2.0 筆記 (4.3) Resource Owner Password Credentials Grant Flow 細節

OAuth 2.0 筆記 (4.4) Client Credentials Grant Flow 細節

各大網站 OAuth 2.0 實作差異 2013

2023/9/11

mDNS DNS-SD

DNS-SD(DNS Service Discovery) 跟 mDNS (multicast DNS) 是不同的 protocol，但可以互相相容。DNS-SD 能透過標準的 DNS 技術，尋找區域網路中，提供某些服務的協定。而 mDNS 是能夠在區域網路中，在不需要 DNS Server 的情況下，就能透過機器名稱，直接查出 IP。

apple 的 Bonjour protocol 就是合併了 mDNS 與 DNS-SD 實作的。

mDNS

可用在沒有 DNS server 的區域網路中，用來作機器 domain name 的 IP 查詢。設備會透過對 224.0.0.251 這個 multicast address，Port 為 5353，進行廣播，mDNS 使用跟 DNS 一樣的封包格式。mDNS 只接受 .local 的網域名稱，可同時運作在一個設備中，跟原本的 DNS 並存。

mDNS 也有為自己命名的功能，在自選了一個 domain name 後，會用記錄類型為 any 的 mDNS 封包查詢是否有同樣的 domain name 的另一台機器，如果沒有，就會設定為自己的 domain name。

DNS-SD

基於 DNS，主要用到三種記錄類型：PTR、SRV、TXT

Service Discovery

設備會先發送一個 PTR 記錄的 multicast 查詢封包，查詢的格式為
```
<service>.<transport>.<domain>
```
service 是查詢的服務，transport 為傳輸協定: TCP 或 UDP，domain 為查詢網域，在 mDNS 為 .local。查詢後，具有該服務的設備就會回應
```
<instance>.<service>.<transport>.<domain>
```
ex: 查詢 _easylink._tcp.local，EMW3031 Module#500A3F._easylink._tcp.local 回應

就表示 EMW3031 Module#500A3F 是符合該 service 的 instance
取得 instance 的 domain name 與 port

當有多個 instance 回應後，選擇某一個 instance，然後需要查詢該 instance 的 domain name 與 port，也就是查詢 SRV 記錄
```
_service._proto.name. TTL class SRV priority weight port target.
```
priority 和 weight 沒有作用，通常設定為 0

port 與 target 就分別是 port 與 domain name

ex:
```
EMW3031 Module#500A3F._easylink._tcp.local. 3 IN SRV 0 0 8002 EMW3031 Module#500A3F.local.
```
更詳細的資訊

除了 domain name 與 port 以外，還能夠提供更多資訊，就是記錄在 TXT record 中，以 key=value 格式記錄的資訊

ex:
```
MAC=D0:BA:E4:50:0A:3F
```

CentOS7 avahi

Avahi is a system which facilitates service discovery on a local network via the mDNS/DNS-SD protocol suite.

安裝 avahi

yum install nss-mdns avahi avahi-tools

啟動

systemctl start avahi-daemon

出現錯誤訊息

 dbus_bus_request_name(): Connection ":1.44573" is not allowed to own the service "org.freedesktop.Avahi" due to security policies in the configuration file

要重新啟動 dbus, NetworkManager

systemctl restart dbus.service

# /var/log/messages 會出現錯誤訊息
# (NetworkManager:624): GLib-GIO-CRITICAL **: Error while sending AddMatch () message: 這個連線已關閉
systemctl restart NetworkManager
# 避免 ssh 登入問題
# Failed to activate service 'org.freedesktop.login1': timed out
systemctl restart systemd-logind

再啟動 avahi-demon

systemctl start avahi-daemon

然後就能查詢 LAN 的機器

# avahi-browse -a
+ enp3s0 IPv4 lzstg [6c:62:6d:ce:71:c7]                     Workstation          local
+ enp3s0 IPv4 macmini2                                      Microsoft Windows Network local
+ enp3s0 IPv4 macmini2                                      Apple File Sharing   local
+ enp3s0 IPv4 macmini2                                      Apple Net Assistant  local
+ enp3s0 IPv4 Michael's MacBook Pro                         Microsoft Windows Network local
+ enp3s0 IPv4 Michael's MacBook Pro                         _companion-link._tcp local

也可以直接 ping *.local 的機器

# ping macmini2.local
PING macmini2.local (192.168.1.159) 56(84) bytes of data.
64 bytes from 192.168.1.159 (192.168.1.159): icmp_seq=1 ttl=64 time=0.675 ms
64 bytes from 192.168.1.159 (192.168.1.159): icmp_seq=2 ttl=64 time=0.374 ms

發布 service

avahi-publish-service SERVICE-NAME _APPLICATIONPROTOCOL._TRANPOSRT-PROTOCOL PORT "DESCRIPTION" --sub SUBPROTOCOL

ex:

avahi-publish-service light _coap._udp 5683 “/mylight” --sub
_floor1._sub._coap._udp

發布 service name: light，使用 CoAP protocol，在 UDP 5683 提供服務

該 service 可透過 _coap._udp.local 及 _floor1._sub._coap._udp.local 被發現

References

UWP - mDNS 找尋附近的設備

MDNS/DNS-SD TUTORIAL

使用 mDNS 在區域網中輕鬆發現系統

Bonjour手把手搭建一：mDNS（apple & multicastdns.org）

區域網設備發現之Bonjour協議

訂閱：文章 (Atom)

2024/9/30

References

2024/9/23

Server

Client

iOS app

References

2024/9/9

Socket Direct Protocol (SDP)

References

2024/8/12

Commands

Headers

Connecting

Heart-beating

Client Frames

SEND

SUBSCRIBE

UNSUBSCRIBE

ACK

NACK

BEGIN

COMMIT

ABORT

DISCONNECT

Server Frames

MESSAGE

RECEIPT

ERROR

Frames and Headers

References

2023/12/4

TSN的應用

影音設備

汽車控制

工業應用

References

2023/10/23

References

2023/10/16

分類

數學模型

網路特徵

建構與維護

結語

References

2023/9/18

角色定義

Grant Flow

Authorization Code Grant Type Flow

Implicit Grant Type Flow

Resource Owner Password Credentials Grant Type Flow

Client Credentials Grant Type Flow

References

2023/9/11

mDNS

DNS-SD

CentOS7 avahi

References