PTPIP協議中文版

原創 nullobject0x01 2019-08-03 00:47

歡迎關注公衆號: nullobject 。
文章首發在個人博客 https://www.nullobject.cn，公衆號nullobject同步更新。

這篇文章主要爲PTPIP的學習筆記

文章目錄

0 說明

本文檔由nullobject對應PTP-IP標準協議1.0版本進行學習整理，原版協議爲英文版，學習時依靠自己理解和使用有道雲翻譯，對理解不到位、翻譯有問題的地方麻煩批評指正。—— by nullobject in 2019-06-03 15:29

1 PTP-IP協議簡介

1.1 目的

本文檔描述了一個基於IP網絡的ISO-15740/PIMA 1574:2000/圖片傳輸協議(PTP)的實現。

PTP被設計用來提供與數字靜止攝影設備的標準通信。該協議指定了標準的圖像引用行爲、操作、響應、事件、設備屬性、數據集和數據格式，以確保互操作性，還提供了可選的操作和格式，以及擴展機制。

1.2 格式規範

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, “OPTIONAL” in this document are to be interpreted as described in “Key words for use in RFCs to Indicate Requirement Levels”[5].

1.3 參考

下表列舉了本文檔的參考資料：

ID/Description
[1] PTP protocol, PIMA 15740:2000
[2] Computer Networks, Andrew S. Tanenbaum, ISBN:0130661023, Prentice Hall Aug 09,2002
[3] UPnP Standard, http://www.upnp.org/resources/documents.asp
[4] ZeroConf Standard, http://www.zeroconf.org
[5] Formatting Conventions. http://www.faqs.org/rfcs/rfc21129.html

1.4 手寫字母縮寫和縮寫詞

縮寫 含義
TCP Transfer Control Protocol
UDP User Datagram Protocol
IP Internet Procotol
PnP Plug and Play
PTP Picture Transfer Protocol
PTP-IP IP Picture Transfer Protocol
PIMA Photographic and Imaging Manufacture Association
DHCP Dynamic Host Configuration Protocol
v4LL IPv4 Link-Local Address

1.5 參與人員

  • Petronel Bigioi – FotoNation Ireland

  • George Susanu – FotoNation Ireland

  • Alexei Pososin – FotoNation Ireland

  • Denis McHugh – FotoNation Ireland

  • Eran Steinberg – FotoNation US

  • Yury Prilusky – FotoNation US

1.6 照片傳輸協議(“PTP”)條款

PTP規範定義了設備角色、操作、圖像格式和其他相機特定的數據類型和結構。在PTP的TCP/IP實現中，所有術語和定義都按照PTP規範中定義的那樣使用。

1.6.1 設備規則

從通信的角度來看，設備可以充當啓動器設備(Initiator)或響應端設備(Responder)，啓動器設備相當於一個客戶端，響應端設備相當於服務端。啓動器設備是向響應端設備發起操作請求的設備。響應端設備則是能夠響應這些操作請求的設備。一個設備可能只是一個啓動器設備，或者只是一個響應端設備，或者兩者兼備，但不能在同一個設備連接上同時擔任兩種角色。

操作請求只能由啓動器設備發起；事件被響應端設備用於把有關它狀態的改變通知啓動器設備。

1.6.2 會話(Session)

根據PTP協議，會話被定義爲兩個設備之間的邏輯連接，操作和事件事務可以通過該邏輯連接進行通信。根據PTP規範，一個響應端設備可以支持多個併發會話，每個會話都有自己的狀態。

當啓動器設備請求OpenSession操作事務時將會打開一個會話，並且使用響應端設備發出的一個有效響應成功結束該請求。

會話將在啓動器設備請求CloseSession操作事務時被關閉，並且使用響應端設備發出的一個有效響應成功結束該請求。當啓動器設備和響應端設備之間的連接被關斷開時會話也會被關閉(例如通信超時)。

大多數操作需要在一個開放會話上下文中執行。不過，不需要打開會話就可以通過GetDeviceInfo操作獲取設備功能。

支持多會話的設備必須能夠使它們彼此保持異步和不透明。

1.6.3 會話ID(SessionID)

通常，如果使用相同傳輸級別的通信通道，則會話ID旨在使響應端設備能夠按適當的順序分發來自不同啓動器設備的請求。對於打開不同通信通道的傳輸，對於每個會話，不需要重新設置會話ID，因爲響應端設備將能夠處理多個會話。

PTP的PTP- IP傳輸實現不會將會話ID發送到響應端設備。響應端設備可以通過控制它允許的最大PTP- IP連接數來限制併發PTP會話的數量。

如果啓動器設備的PTP-IP層發現響應端設備不接受新的PTP-IP連接，它將向PTP層發送傳輸特定的錯誤代碼。在建立傳輸指定連接之後，啓動端設備可以向遠程響應端設備發出GetDeviceInfo和OpenSession請求。在這個階段中，響應端設備可能返回一個設備繁忙(Device_Busy)的PTP錯誤作爲對OpenSession的響應(如果響應端設備對它能夠支持的併發PTP會話的數量有限制)。在這種情況下，啓動端設備應該釋放PTP連接，並稍後重試。

1.6.4 事務(Transactions)

事務是PTP協議中操作的基本單位，PTP協議規定的所有操作都基於事務進行。事務操作請求由啓動器設備(Initiator)發起，傳送到到響應端設備(Responder)，在一個會話(Session)中，同一時間只能有一個事務操作在執行，操作事務在一個會話中默認是同步的。

一個事務通常由三個階段組成：Operation Request、Operation Response、Data Phase，如下圖：

Transaction基本組成

取決於事務操作本身，Data Phase這一可選階段可能不會存在於一個事務流程中，即事務只有Operation Request和Operation Response。而當事務中存在Data Phase時，數據可能從初始化器Initiator發送到響應設備Responder(即I–>R)，或者反過來R–>I，但同一個操作中數據只能在一個方向上傳輸。

1.6.5 事務ID(TransactionID)

事務ID(TransactionID)用於在一個給定的會話中標識不同事務，與在PTP協議的第9.3.1項中定義的事務ID相同，是一個32位無符號整型數字。事務ID在給定的會話中是唯一且連續的數字序列，其範圍從0x00000001到0xFFFFFFFE，0x00000000和0xFFFFFFFF作爲保留值不被使用。

1.7 與PTP協議一致性

在PTP標準協議的**7[1]**節中，爲底層傳輸層定義了這些需求。

  • PTP標準協議 7.1節：斷開事件。PTP協議的這一節要求傳輸層必須向上層的報告設備斷開。這是通過PTP-IP 層生成設備斷開通知來實現的。

  • PTP標準協議 7.2節：穩定、無錯誤通道。PTP協議的這節要求需要可靠，無錯誤的通道。在PTP-IP中，這通過使用配置了Keep Alive選項的TCP連接來實現。

  • PTP標準協議 7.3節：異步事件的支持。PTP要求支持異步事件，在PTP-IP中，事件連接被定義爲用於傳輸異步事件，並且與命令/數據通道是異步的。

  • PTP標準協議 7.4節：設備發現和枚舉。PTP要求支持設備發現和枚舉服務，在PTP-IP中，設備發現和枚舉使用對IP網絡可用的通用解決方案來實現，可以使用一個基於設備發現協議[5]的自定義UDP協議。

  • PTP標準協議 7.5節：傳輸特定。PTP要求圖像設備傳輸的實現符合相關機構發佈的特定使用傳輸規範。本文檔說明了如何使用位於TCP/IP協議棧上層的PTP-IP傳輸。

2 PTP-IP實現

2.1 PTP-IP協議模型

在PTP-IP的實現中，用戶程序與PTP-IP層之間的通信基於PTP事務模型實現，參考PTP協議的**9.3[1]**節，該通信模型如下圖：

PTP-IP協議模型

本文檔的目的在於制定和說明PTP-IP通信協議，應用程序和PTP-IP層（編程接口，API）之間交互的實現並不在本文檔的內容範圍內。本文檔僅以互操作性的方式規定兩個PTP-IP實體之間的通信。不過，PTP層（用戶應用程序）和PTP-IP層之間的接口可能由以下基本類型組成：

  • 操作請求(Operation Request)

    每當進行請求操作時，啓動器設備(Initiator)中的應用程序就會發送一個操作請求，隨即該請求被響應端設備(Responder)接受。操作請求中通常包含一組與該操作相關的參數。

  • 操作響應(Operation Responses)

    每當接收到一個操作請求，響應端設備(Responder)會發送一個操作響應作爲該操作請求的迴應。對於啓動器設備(Initiator)中應用程序發起的每個操作請求，都需要回復一個操作響應。操作響應中總是會包含其對應的操作請求的結果代碼，並且可能會包含一組參數。

  • 數據讀入(Data-In)

    數據讀入(Data-In)是相對於用於應用程序而言的，即數據流向是從響應端設備(Responder)到啓動器設備(Initiator)。

  • 數據寫出(Data-Out)

    數據寫出(Data-Out)的數據流與數據讀入(Data-In)相反。

  • 事件(Events)

    PTP-IP中的事件是指有關響應端設備(Responder)的狀態變更的通知，事件由響應端設備啓動。

  • 設備連接/斷開(Device Connect/Disconnect)

    設備的連接/斷開是平臺相關類型的事件。這兩個事件並不直接在啓動器設備和響應端設備之間通信，而是當檢測到設備被連接/斷開時由各自的PTP-IP層生成。

操作和事件兩種事務的類型的定義在PTP協議文檔的10.11、**12 [1]節中可以找到，並且PTP協議在14 [1]**節中爲設備標準的一致性確定了一組操作和事件。

2.2 PTP-IP傳輸模型

PTP標準協議文檔的**7 [1]**節定義了PTP標準傳輸需求，而PTP-IP則是基於使用TCP層作爲傳輸層實現：

PTP-IP傳輸模型

與PTP一樣，PTP-IP也期望從其傳輸層獲得可靠、穩定無錯誤的通信通道，而TCP(位於TCP/IP協議棧中)正是可以滿足這些需求的自然傳輸層。TCP是一個基於流的傳輸層，它提供多個通信通道(TCP Connection)和無錯誤的數據傳輸。

在PTP-IP中，兩個設備之間的所有通信都通過兩個TCP連接(邏輯數據通道)進行：

PTP-IP通信模型

由於事件本身具有異步性質，事件的數據包與操作/數據事務數據包分開分別通過兩個單獨的通道傳輸。

2.2.1 命令/數據連接(Command/Data TCP Connection)

PTP-IP的 命令/數據連接用於傳輸PTP操作請求、響應和數據事務，以及特定於PTP-IP的數據包。該連接由啓動器設備(Initiator)建立，並標誌本地及響應端設備(Responder)的IP地址和端口號。響應端設備(Responder)的IP地址和端口號通常是通過設備發現機制來確定。

2.2.2 事件連接(Event TCP Connection)

PTP-IP的事件連接作爲啓動器設備(Initiator)開啓的與響應端設備(Responder)之間的第二個連接，用於傳輸PTP事件，以及特定於PTP-IP的數據包。與命令/數據連接相同，事件連接由啓動器設備(Initiator)發起建立， 並標誌本地和響應端設備(Responder)的IP地址和端口號，響應端設備(Responder)的IP地址和端口號通常是通過設備發現機制來確定。

2.2.3 傳輸通道管理

2.2.3.1 建立PTP-IP連接

在啓動器設備(Initiator)與響應端設備(Responder)之間的通信中，每當需要這些傳輸通道時，啓動器設備(Initiator)將負責發起與響應端設備(Responder)的PTP-IP/TCP連接。如前文所述，PTP-IP的傳輸通道使用TCP連接實現：一個通道用於命令/數據傳輸，另一個則用於事件傳輸。每個通道都會標誌本地以及響應端設備(Responder)IP地址和端口號。從PTP-IP的通信模型中可以看到，啓動器設備(Initiator)的PTP-IP實際上是一個TCP客戶端，對應地響應端設備(Responder)的PTP-IP則是一個TCP服務器。響應端設備(Responder)輪詢等待連接請求，並且預定義(或者動態分配)了一個TCP連接端口號.PTP-IP服務端默認端口號爲15740。PTP-IP連接建立過程：

PTP-IP連接建立過程

PTP-IP中的TCP連接應遵循上圖所示順序進行：

  1. 啓動器設備(Initiator)發起命令/數據的TCP連接：指定響應端設備(Responder)的IP地址和端口號，並連接到響應端設備(Responder)；

  2. TCP連接建立成功後，啓動器設備(Initiator)立即發送一個Init Command Request包，數據包中需要包含啓動器設備(Initiator)的唯一標識(GUID和啓動器設備的用戶友好名稱)，例如：

    PTP-IP CmdReq數據包示例

  3. 響應端設備(Responder)程序根據實際情況，回覆啓動器設備一個Init Command Ack包以告知啓動器設備請求成功並且可以繼續進行連接；或者回復Init Fail數據包表示請求失敗，以告知啓動器設備請求訪問被拒絕，並且斷開命令/數據的TCP連接，同時啓動器設備接收到請求失敗的迴應後也應該斷開相應的的命令/數據連接。

  4. 啓動器設備(Initiator)接收到Init Command Ack包後，繼續發起一個事件的TCP連接：指定響應端設備(Responder)的IP地址和端口號，並連接到響應端設備(Responder)。注意該連接與第1步中的連接是區別開的。

  5. 一旦連接建立成功，啓動器設備(Initiator)立即發送一個Init Event Request包，數據包需要包含第4步驟中接收到的連接號(Connection Number)。響應端設備(Responder)需要根據這個連接號將命令/數據和事件兩個TCP連接關聯同一個PTP-IP連接和同一個PTP會話。

  6. 與步驟3類似，請求成功則回覆一個Init Event Ack包，在響應端設備(Responder)資源不足時，回覆Init Fail包告知啓動端請求失敗。

  7. 一旦啓動器設備(Initiator)接收到步驟6中回傳的Init Event Ack包則認爲請求成功，此時PTP-IP連接真正建立完成，接着即可進行進一步的數據通信。

在第二個TCP連接(事件連接)建立失敗的情況下，第一個TCP連接(命令/數據連接)需要被關閉，稍後啓動器設備(Initiator)應再次嘗試建立PTP-IP連接。建議每次創建PTP-IP連接的時間間隔爲30s。

2.2.3.2 傳輸通道配置

根據PTP協議**7 [1]**節，PTP-IP層要求傳輸通道可靠、無錯誤。這種傳輸通道可以通過正確配置TCP連接來實現。

PTP-IP的TCP連接應該使用一下選項創建：

  • Keep Alive 選項：啓動器和響應端需要同時需要同時開啓這個選項，以確保兩端的TCP實體在非活躍時期能夠維持連接。開啓這個選項後，啓動器和響應端各自的TCP棧會通過TCP協議特定的方式來檢查所配對的設備是否仍舊能夠響應。這種檢查方式是在TCP層進行，對上層的PTP-IP來說是透明的。

  • 禁用Nagle算法：需要在啓動器和響應端程序的TCP/IP協議棧上禁用Nagle算法，以避免在傳輸命令代碼和響應時出現不必要的延遲。

總的來說就是需要設置如下選項(Qt爲例)：

// 禁用Nable算法
mTcpSocket->setSocketOption(QAbstractSocket::SocketOption::LowDelayOption,1);
// 開啓Keep Alive選項
mTcpSocket->setSocketOption(QAbstractSocket::SocketOption::KeepAliveOption,1);
2.2.3.3 關閉PTP-IP連接

當不再需要PTP-IP時，由啓動器設備(Initiator)關閉連接。當啓動器設備(Initiator)或者響應端設備(Responder)在打開的傳輸通道上發生錯誤而導致這些通道不穩定時，也應關閉PTP-IP連接。關閉PTP-IP連接時兩個TCP連接(命令/數據連接和事件連接)都必須要關閉。

2.3 傳輸的數據包類型

本節主要介紹用於在啓動器設備(Initiator)和響應端設備(Responder)間通信的一組數據包類型。PTP-IP的數據包類型相當於PTP協議中定義的操作請求(Operation Request)、響應(Response)、**數據(Data)和事件(Event)事務類型。PTP-IP數據包中的所有多字節值都使用小端(Little-Endian)**格式表示，通常一個PTP-IP數據包的格式如下：

Field Size[Bytes] Data Type
Length 4 UINT32
Packet Type 4 UINT32
Payload 根據Length計算 ？

  • 長度(Length)：4字節，長度參數決定了包含包頭在內的整個數據包的大小；

  • 包類型(Packet Type)：4字節，該字段標誌了數據包的類型，該參數有下列可選的值：0x0000NNNN*表示隱藏值。

Value Description
0x00000000 保留值
0x0000NNNN* Init Command Request Packet
0x0000NNNN* Init Command Ack
0x0000NNNN* Init Event Request Packet
0x0000NNNN* Init Event Ack Packet
0x0000NNNN* Init Fail Packet
0x0000NNNN* Operaqion Request Packet
0x0000NNNN* Operation Response Packet
0x0000NNNN* Event Packet
0x0000NNNN* Start Data Packet
0x0000NNNN* Data Packet
0x0000NNNN* Cancel Packet
0x0000NNNN* End Data Packet
0x0000NNNN* Probe Request Packet
0x0000NNNN* Probe Response Packet
0x0000NNNN* - 0xFFFFFFFF 保留值
  • 負載(Payload)：包含協議更上層的或者是傳輸特定的數據。

2.3.1 Init Command Request Packet

該數據包在命令/數據傳輸通道被建立後立即被啓動器設備(Initiator)發送。該數據包通過命令/數據連接傳輸，用於通知響應端設備(Responder)對啓動器進行標識，從而使響應端設備(Responder)能夠實現過濾機制。數據包結構如下：

Field Size[Bytes] Data Type
Length 4 UINT32
Packet Type 4 UINT32
Initiator GUID 16 UINT8
Initiator Friendly Name Variable UINT16
Initiator Protocol Version 4 UINT32
  • Initiator GUID：16字節，啓動器設備的全局唯一標識符；
  • Initiator Friendly Name：啓動器設備的用戶友好名稱，該字段是一個包含啓動器設備描述信息的Unicode字符串，該字串通常用於響應端設備的UI顯示上(以確認或拒絕來自給定啓動器設備的連接請求)；
  • Initiator Protocol Version：4字節，啓動器設備端實現的協議版本號。該字段由一個主版本號(高16位)和一個子版本號(低16位)組成。該字段應該被設置成第[3](# 3 協議版本)節中定義的BINARY PROTOCOL VERSION。
  • 啓動器設備的GUID和響應端設備的GUID可用於進行設備綁定。若啓動器設備的GUID的16個字節全由0xFF組成，則表示該啓動器設備是一個匿名設備，此時由響應端設備決定是否允許連接。更多信息參考[附錄5.3](#5.3 設備綁定和認證)。
  • 啓動器設備的用戶友好名稱是一個以**空(NULL)字符結尾的Unicode字符串。包括結尾的空字符，其最大長度位40個字節。不使用該字段時，必須使用一個空(NULL)**字符填充該字段。

數據包示例：

PTP-IP CmdReq數據包示例

對應地：

  • 30 00 00 00：第0~3字節表示Length字段
  • 01 00 00 00：第4~7字節表示Packet Type字段
  • fc 47 f8 4e 30 97 ee 64 1c 26 38 ae b0 1a 9e ac：第8~23字節表示Initiator GUID字段
  • 44 00 53 00 43 00 2d 00 52 00 58 00 30 00 4d 00 32 00 00 00：第**24~(Length-4-4-16-4-1)**字節表示Initiator Friendly Name字段
  • 00 00 01 00：最後4字節表示Initiator Protocol Version字段。

2.3.2 Init Command ACK Packet

該數據包由響應端設備(Responder)回傳給啓動器設備，以響應啓動器設備發送的Init Command Request Packet，併爲接下來的PTP-IP會話分配一個連接號(Connection Number)，該數據包在命令/數據連接上傳輸。

包結構如下：

Field Size[Bytes] Data Type
Length 4 UINT32
Packet Type 4 UINT32
Connection Number 4 UINT32
Responder GUID 16 UINT6
Responder Friendly Name Variable UINT16
Responder Protocol Version 4 UINT32
  • Connection Number：連接號，是響應端設備生成的用於關聯所有屬於同一個PTP會話的TCP連接通道的唯一值。
  • Responder GUID：響應端設備的GUID。
  • Responder Friendly Name：響應端設備的用戶友好名稱，可用於啓動器設備端的UI顯示。
  • Responder Protocol Version：響應端設備實現的協議版本號。該字段由一個主版本號(高16位)和一個子版本號(低16位)組成。該字段應該被設置成第3節中定義的BINARY PROTOCOL VERSION。
  • 響應端設備的用戶友好名稱是一個以**空(NULL)字符結尾的Unicode字符串。包括結尾的空字符，其最大長度位40個字節。不使用該字段時，必須使用一個空(NULL)**字符填充該字段。
  • 連接號在啓動器設備和響應端設備連接被建立的期間保持有效。一旦響應端設備成功關聯屬於同一個PTP-IP連接的兩個TCP連接，連接號即可被重新使用。

實際該數據包結構看起來如下：

PTP-IP CmdAck數據包示例

對應地：

  • 34 00 00 00：第0~3字節表示Length字段
  • 02 00 00 00：第4~7字節表示Packet Type字段
  • 01 00 00 00：第8~11字節表示Connection Number字段
  • 00 00 00 00 00 00 00 00 ff ff 10 98 c3 d1 5f 45：第12~27字節表示Responder GUID字段
  • 44 00 53 00 43 00 2d 00 52 00 58 00 30 00 4d 00 32 00 00 00：第**28~(Length-4-4-4-16-4-1)**字節表示Responder Friendly Name字段
  • 00 00 01 00：最後4字節表示Responder Protocol Version字段。

2.3.3 Init Event Request Packet

命令/數據連接被成功建立後，該數據包被啓動器設備發送至響應端設備用於建立事件連接。啓動器設備在接收到一個有效的Init Command Ack Packet數據包後，立即建立事件的TCP連接併發送Init Event Request Packet數據包，包中攜帶的連接號即前面步驟中接收到的在Init Command Ack數據包中返回的連接號。Init Event Request數據包通過事件連接傳輸。

包結構如下：

Field Size[Bytes] Data Type
Length 4 UINT32
Packet Type 4 UINT32
Connection Number 4 UINT32
  • Connection Number：連接號，從Init Command Ack Packet包數據中獲得。

數據包示例：

PTP-IP EventReq數據包示例

對應地：

  • 0c 00 00 00：第0~3字節表示Length字段
  • 03 00 00 00：第4~7字節表示Packet Type字段
  • 01 00 00 00：第8~11字節表示Connection Number字段

2.3.4 Init Event ACK Packet

該數據包由響應端設備(Responder)通過事件連接通道回傳給啓動器設備，以告知啓動器設備PTP-IP連接建立成功。

包結構如下：

Field Size[Bytes] Data Type
Length 4 UINT32
Packet Type 4 UINT32

數據包示例：

PTP-IP EventAck數據包示例

對應地：

  • 08 00 00 00：第0~3字節表示Length字段
  • 04 00 00 00：第4~7字節表示Packet Type字段

2.3.5 Init Fail Packet

初始化失敗數據包。當PTP-IP連接建立失敗時，該數據包由響應端設備(Responder)回傳給啓動器設備，以告知啓動器設備連接建立失敗及失敗原因，失敗原因被記錄在Reason字段。接收到該數據包之後，啓動器設備必須關閉先前步驟中建立的命令/數據連接。該數據包發出後，響應端設備亦應關閉相應的PTP-IP連接(由啓動器設備發起的被拒絕的TCP連接)。Init Fail Packet可以通過任意的TCP連接傳輸。更多有關PTP-IP連接的建立可以參考PTP-IP連接一節內容。

Field Size[Bytes] Data Type
Length 4 UINT32
Packet Type 4 UINT32
Reason 4 UINT32

Reason字段包含了連接拒絕的錯誤碼，該字段定義的錯誤碼有以下幾種：

  • 0x0000NNNN*：FAIL_REJECTED_INITIATOR，表示響應端設備實現了一個設備綁定的機制，但請求連接的啓動器設備不在允許的設備集合內。參考[附錄5.3](#5.3 設備綁定和認證)瞭解綁定機制詳情。
  • 0x0000NNNN*：FAIL_BUSY，表示響應端設備繁忙：響應端設備的活動連接數過多。啓動器設備可以稍後再嘗試連接。
  • 0x0000NNNN*：FAIL_UNSPECIFIED，其他原因。

2.3.6 Operation Request Packet

操作請求數據包。該數據包在PTP-IP協議中用於傳輸在PTP標準協議**9.3.2 [1]**節定義的PTP操作請求。PTP-IP Operation Request Packet由啓動器設備發送至響應端設備，並通過命令/數據通道傳輸。

包結構如下：

Field Size[Bytes] Data Type
Length 4 UINT32
Packet Type 4 UINT32
Data Phase Info 4 UINT32
Operation Code 2 UINT16
TransactionID 4 UINT32
Parameter1 4 UINT32
Parameter2 4 UINT32
Parameter3 4 UINT32
Parameter4 4 UINT32
Parameter5 4 UINT32
  • Data Phase Info：指示下一個數據階段是**數據寫(data out)階段還是數據讀/數據(data in/no)**階段，該字段值被定義爲下列幾種：
    • 0x0000NNNN*：**無數據或數據讀(data in/no)**階段：啓動器設備不知道響應端設備是否會提供一些數據或者提供一個響應；
    • 0x0000NNNN*：**數據寫(data out)**階段
    • 0x0000NNNN*：未知的數據階段
  • Operation Code：操作碼，包含定義在PTP標準協議**第10.2和10.3 [1]**節的PTP操作碼。
  • TransactionID：事務ID，它在當前連接的響應端設備的開放會話上下文中是唯一的，如PTP第9.3.1 [1]節中定義。TransactionID是一個從0x00000000到0xFFFFFFFF的連續數值。0x00000000作爲特殊的值，只能被用於OpenSession或GetDeviceInfo兩個操作請求，每次當此參數不適用於包時，必須使用另一個特殊值0xFFFFFFFF。
  • Parameter 1~5：這些字段包含特定於操作的參數，這些參數的解釋取決於操作碼(Operation Code)參數，一個操作最多可以容納5個參數。這些參數的使用方式定義在PTP標準協議的**10.1和10.4 [1]**節。
  • 如果Data Phase Info字段被設置爲Data Out Phase，則在發送該數據包後接着必須要發送一個Start Data Packet包。
  • 如果啓動器設備需要發送空數據對象到響應端設備，有兩個選項可選：1.將Data Phase Info字段設置爲No data or data in phase，在這情況下響應端設備將會直接回應一個Operation Response Packet包，而不會等待Data Packet；2.將Data Phase Info字段設置爲Data out Phase.在這種情況下，數據寫階段(data out phase)必須只包含一個Start Data Packet包，並將該包的Total Data Length字段設置爲0x00000000，並且啓動器設備必須不能發送後續的End Data Packet數據包。

實際該數據包結構如下：

PTP-IP OperationReq數據包示例

對應地：

  • 16 00 00 00：第0~3字節表示Length字段
  • 06 00 00 00：第4~7字節表示Packet Type字段
  • 02 00 00 00：第8~11字節表示Data Phase Info字段
  • 05 92：第12~13字節爲Operation Code字段
  • 06 00 00 00：第14~17字節爲Transaction ID字段
  • 0e 50 00 00：第18~21字節爲Parameter 1字段

2.3.7 Operation Response Packet

操作響應數據包。該數據包在PTP-IP協議中用於傳輸在PTP標準協議9.3.4 [1]節定義的PTP操作響應。PTP-IP Operation Response Packet數據包由響應端設備通過命令/數據通道迴應給啓動器設備。操作響應數據包僅在需要指示操作請求事務已經結束並且需要傳遞操作結果時才由響應端設備發送給啓動器設備。

包結構如下：

Field Size[Bytes] Data Type
Length 4 UINT32
Packet Type 4 UINT32
Response Code 2 UINT16
TransactionID 4 UINT32
Parameter1 4 UINT32
Parameter2 4 UINT32
Parameter3 4 UINT32
Parameter4 4 UINT32
Parameter5 4 UINT32
  • Response Code：響應碼，包含定義在PTP標準協議第11.1和11.3 [1]節的操作響應碼。
  • TransactionID：事務ID，它在連接到響應端設備的開放會話上下文中是唯一的，如PTP第9.3.1[11]節中定義。TransactionID是一個從0x00000001到0xFFFFFFFE的連續數值。0x00000000作爲特殊的值，只能被用於OpenSession或GetDeviceInfo兩個操作請求，每次當此參數不適用於包時，必須使用另一個特殊值0xFFFFFFFF。
  • Parameter 1~5：這些字段包含特定於操作的參數，這些參數的解釋取決於生成響應的操作以及特定的響應代碼值。一個操作響應的數據包最多可以容納5個參數。這些參數的使用方式定義在PTP標準協議的**9.3.4 [1]**節。

實際該數據包結構如下：

PTP-IP OperationRep數據包示例

對應地：

  • 0e 00 00 00：第0~3字節表示Length字段
  • 07 00 00 00：第4~7字節表示Packet Type字段
  • 01 20：第8~9字節表示Response Code字段
  • 05 00 00 00：第10~13字節爲Transaction ID字段

2.3.8 Event Packet

事件數據包。該數據包用於傳輸在PTP標準協議**12.2 [1]**節中定義的事件。這些事件由響應端設備通過事件連接通道發送給啓動器設備，以通知啓動器設備響應端的狀態變更。

包結構如下：

Field Size[Bytes] Data Type
Length 4 UINT32
Packet Type 4 UINT32
Event Code 2 UINT16
TransactionID 4 UINT32
Parameter1 4 UINT32
Parameter2 4 UINT32
Parameter3 4 UINT32
  • Event Code：事件碼，包含定義在PTP標準協議第12.3和12.4 [1]節的事件碼。
  • TransactionID：事務ID，它在當前連接到響應端設備的開放會話上下文中是唯一的，其定義在PTP標準協議的9.3.1 [1]節。如果事件數據包對應於先前發起的事務，則該字段應該被設爲操作所對應的事務ID。如果事件沒有指定於特定的事務，則該字段應設爲0xFFFFFFFF。
  • Parameter 1~3：這些字段包含特定於事件的參數。這些參數的解釋卻決於事件碼(Event Code)字段。一個Event Packet數據包最多能容納3個參數，有關這些參數的使用說明定義在PTP標準協議的**12.5 [1]**節。

2.3.9 Start Data Packet

開始數據傳輸數據包。該數據包在PTP-IP中用於標識數據傳輸的開始。其通過命令/數據通道傳輸，可以由任意一設備端發送，另一端接收。

包結構如下：

Field Size[Bytes] Data Type
Length 4 UINT32
Packet Type 4 UINT32
TransactionID 4 UINT32
Total Data Length 8 UINT64
  • Total Data Length：包含即將在數據讀(data in)階段或數據寫(data out)階段中被傳輸的數據大小。特定的值0xFFFFFFFFFFFFFFFF表示在數據階段的開始並不知道數據的大小，該值的使用僅限於傳輸對象的大小未知的情況(例如：傳輸流數據)。

數據包示例：

PTP-IP StartDataPacket數據包示例

其中：

  • 14 00 00 00：第0~3字節表示Length字段
  • 09 00 00 00：第4~7字節表示Packet Type字段
  • 01 00 00 00：第8~11字節表示Transaction ID字段
  • 08 00 00 00 00 00 00 00：第12~19字節爲Total Data Length字段

2.3.10 Data Packet

該數據包在PTP-IP中用於傳輸數據。Data Packet包只在數據階段使用，且可以由當前數據流方向上的任意一端發送，另一端接收：在**數據讀(data-in)階段由響應端設備發送給啓動器設備；在數據寫(data-out)**階段由啓動器設備發送給響應端設備。Data Packet數據包走的是命令/數據的連接通道。

由於TCP傳輸是無錯誤、基於流的協議，通常不需要對大型的數據包進行拆包和粘包操作。不過可以使用基本的碎片機制來實現一個簡單的數據傳輸取消機制，Data Packet不需要進行錯誤校驗。

包結構如下：

Field Size[Bytes] Data Type
Length 4 UINT32
Packet Type 4 UINT32
TransactionID 4 UINT32
Data Payload ? UINT8
  • Data Payload：包含數據包中需要傳輸的數據。

數據包示例：

PTP-IP DataPacket數據包示例

其中：

  • 14 00 00 00：第0~3字節表示Length字段
  • 0a 00 00 00：第4~7字節表示Packet Type字段
  • 01 00 00 00：第8~11字節表示Transaction ID字段
  • 00 00 00 00 00 00 00 00 0c 00 00 00 0c 00 00 00 01 00 00 00 0e 00 00 00 07 00 00 00 01 20 01 00 00 00：第12~N字節爲Data Payload字段。

2.3.11 End Data Packet

終結數據傳輸的數據包。End Data Packet數據包在PTP-IP中用於標識數據階段的結束，該數據包中也可以攜帶一些有用數據。該數據包只在一個事務的數據階段使用，可以由數據流方向上的任意一端發送，另一端接收：在**數據讀(data-in)階段由響應端設備發送給啓動器設備；在數據寫(data-out)**階段由啓動器設備發送給響應端設備。

包結構如下：

Field Size[Bytes] Data Type
Length 4 UINT32
Packet Type 4 UINT32
TransactionID 4 UINT32
Data Payload ? UINT8
  • Data Payload：如果數據包中包含有數據則放在這個字段。

數據包示例：

PTP-IP EndDataPacket數據包示例

其中：

  • 10 00 00 00：第0~3字節表示Length字段
  • 0c 00 00 00：第4~7字節表示Packet Type字段
  • 06 00 00 00：第8~11字節表示Transaction ID字段
  • 02 00 01 00：第**12~(Length-4-4-4)**字節爲Data Payload字段。

2.3.12 Cancel Packet

Cancel Packet數據包用於取消傳輸事務，由啓動器設備發送至響應端設備。該數據包在命令/數據連接通道和事件連接通道上發送。

包結構如下：

Field Size[Bytes] Data Type
Length 4 UINT32
Packet Type 4 UINT32
TransactionID 4 UINT32

2.3.13 Probe Request Packet

心跳包。該數據包可用於PTP-IP的啓動器設備和響應端設備，以檢查對等設備是否仍然有效。當接收到該數據包時，設備必須立即響應一個Probe Response Packet數據包。如果在一段合理的時間內沒有收到響應，則發出該數據包的設備將關閉與對端設備的PTP-IP會話。

包結構如下：

Field Size[Bytes] Data Type
Length 4 UINT32
Packet Type 4 UINT32

數據包示例：

PTP-IP ProbeRequestPacket數據包示例

其中前、後四個字節分別爲Length字段和Packet Type字段。

使用該數據包時應要注意控制發送的頻率以避免造成局域網過載：

  • 啓動器設備發送至響應端設備(I–>R)：建議這個包只在PTP事務中使用(例如，當發出格式命令時，如果存儲介質很大，響應時間可能會很長)，以便檢查響應端設備是否仍然處於活躍狀態。
  • 響應端設備發送至啓動器設備(R–>I)：建議僅當響應端設備接收到一個新的PTP-IP會話的請求，而另一個或多個其他會話處於活動狀態時，才使用此包。在這種情況下，響應端設備可以檢查現有的PTP-IP連接是否仍然處於活動狀態。
  • 建議在發送Probe Request Packet數據包和接收Probe Response Packet包之間設置10秒的超時時間。

2.3.14 Probe Response Packet

心跳包的迴應數據包。該數據包可用於PTP-IP的啓動器設備和響應端設備，作爲另一端的Probe Request Packet請求的響應。當接收到一個Probe Request Packet請求時應當立即回覆這個數據包。

包結構如下：

Field Size[Bytes] Data Type
Length 4 UINT32
Packet Type 4 UINT32

數據包示例：

PTP-IP ProbeResponsePacket數據包示例

其中前、後四個字節分別爲Length字段和Packet Type字段。

2.4 會話的實現

由啓動器設備在PTP層發起的新會話請求將生成兩個新的TCP連接，這兩個連接即對應於PTP-IP層的**命令/數據(Command/Data)連接和事件(Event)連接。這兩個TCP連接足夠用來唯一標識其所屬的會話，因此不需要將會話ID(SessionID)**作爲獨立的值從啓動器設備發送到響應端設備。

2.5 設備斷開和網絡丟失處理

在PTP-IP協議中，對設備的斷開或者網絡丟失的檢測基於以下一些標準：

  • 網絡層通知應用程序有關網絡連接斷開(例如媒體斷開連接)的功能。
  • 任意一個PTP-IP連接通道丟失(命令/數據通道或事件通道)，例如socket被破壞。
  • 任意一個PTP-IP通道傳輸超時。

2.6 數據流控制

爲了防止一個設備在事務的數據階段用數據重載另一個設備，通常會實現一個數據流控制機制。不過在PTP-IP中不需要實現這樣的機制，因爲底層的TCP層會執行流控制操作。

TCP層在兩個級別實現流控制：接收設備和網絡，避免在低速接收和低速網絡下數據氾濫。因此，在PTP-IP中採用TCP連接作爲通信通道，直接解決了流量控制的問題。

2.7 事務取消機制

有兩種可能取消事務的情況：啓動器設備請求取消或者響應端設備請求取消。

2.7.1 啓動器設備產生的取消

2.7.1.1 數據寫階段

啓動器設備爲了取消正在進行的數據寫階段傳輸，必須在命令/數據通道和事件通道上發出一個Cancel Packet數據包，並停止任何正在命令/數據通道上的數據傳輸。當響應端設備在命令/數據通道或事件通道上收到Cancel Packet數據包時，必須儘可能快地中斷並取消正在進行的事務，同時讀取和丟棄所有屬於當前事務(如果有)的剩餘的數據包，並且向啓動器設備迴應一個附帶有Transaction_Cancelled響應碼的Operation Response Packet數據包。

2.7.1.2 數據讀階段

啓動器設備爲了取消正在進行的數據讀階段傳輸，必須在命令/數據通道和事件通道上發出一個Cancel Packet數據包。響應端設備在命令/數據通道或事件通道上收到Cancel Packet數據包時，必須儘可能快地中斷並取消正在進行的事務，並且向啓動器設備迴應一個附帶有Transaction_Cancelled響應碼的Operation Response Packet數據包。

2.7.1.3 其他事務階段

啓動器設備可以通過在命令/數據通道和事件通道上發出一個Cancel Packet數據包以在事務的任意階段退出事務。如果取消的是當前的事務，則響應端設備必須迴應一個附帶有Transaction_Cancelled響應碼的Operation Response Packet數據包。

2.7.2 響應端設備產生的退出

2.7.2.1 數據寫階段

響應端設備爲了取消正在進行的數據寫階段傳輸，必須發送一個附帶有Transaction_Cancelled或者其他標識數據傳輸中斷原因的響應碼的Operation Response Packet數據包。然後，響應端設備必須讀取和丟棄所有屬於當前事務的在命令/數據通道中的Data Packet數據包。

2.7.2.2 數據讀階段

響應端設備爲了取消正在進行的數據讀階段傳輸，必須在命令/數據通道上發送一個Operation Response Packet數據包，並且附帶Transaction_Cancelled響應碼或其他標識數據傳輸中斷原因的響應碼。

2.7.2.3 其他事務階段

響應端設備可以通過發送附帶Transaction_Cancelled響應碼或其他標識數據傳輸中斷原因的響應碼的Operation Response Packet以在事務的任意階段退出事務。

2.7.3 異步操作退出機制

啓動器設備爲了取消一個異步操作，必須同時在命令/數據通道和事件通道發送一個包含該異步操作所屬的事務ID的Cancel Packet數據包，啓動器設備可以在任意時候發送這些數據包。

響應端設備將以PTP事件(例如Capture Complete event)結束操作。解釋取消請求的邏輯由響應端設備的應用層負責。

3 協議版本

該PTP-IP規範的二進制協議版本(BINARY PROTOCOL VERSION)是0x00010000(1.0版)。二進制協議版本由一個主要數字(高16位表示)和一個次要數字(低16位表示)組成。這個數字將增加，以表示較新的協議版本，方法如下:

  • 次要版本進行了增加，以反映協議規範中的次要更改。實現新次要版本的設備必須完全支持同一主要版本的所有次要版本。
  • 主要版本增加了，以反映協議規範中的主要更改。新協議規範可能與主號碼較小的舊規範版本不兼容。

4 PTP-IP端口

如果沒有實現設備發現協議，則每一個響應端設備和啓動器設備應該通過以下端口號來初始化：

Port Name Port No. Type Description
PTP-IP service 15740 TCP 響應端設備等待TCP連接的默認端口，該端口由IANA批准。

5 附錄

5.1 地址配置

PTP-IP協議的基礎是TCP/IP協議，該協議的關鍵是尋址機制。響應端設備和啓動端程序都將獲得有效的IP地址。獲取有效IP地址的方法有以下幾種:

  • 手動配置： IP地址和其他網絡屬性由用戶手動配置，以反映圖像設備將在其中工作的局域網的拓撲結構和地址模式；
  • 基於DHCP配置：圖像設備應實現一個DHCP客戶端，DHCP客戶端將自動從網絡中的DHCP服務器獲取IP地址。
  • IPv4鏈路本地地址(v4LL)的動態配置：一個描述了一種在TCP/IP局域網上自動自配置網絡設備的機制，而無需設置DHCP服務器的標準。

爲了處理設備的TCP/IP屬性配置，建議執行以下步驟：

  • 如果屬性是手動配置的，則使用該配置；
  • 否則設備應使用DHCP協議獲取IP地址以及其他配置參數(設備需要實現一個DHCP客戶端)；
  • 如果網絡中沒有DHCP服務器，則可以部署v4LL動態配置。

5.2 設備發現和枚舉

在PTP-IP中，啓動器設備可以通過以下幾種方式配置連接到響應端設備的地址：

  • 手動配置：啓動器設備將手動配置它可以連接的響應端設備的一個或一組地址。啓動器設備會嘗試根據IP地址建立一個PTP-IP連接，如果連接成功則說明響應端設備存在，此時可以建立一個PTP會話。
  • Zeroconf：一族提供自動配置、設備和服務發現的協議和建議，在**IETF Zeroconf Working Group.[4]**中發表。
  • UPnP：一組發表在**UPnP Forum[3]**用於簡化設備配置、服務發現和調用的協議。僅可以使用該協議的設備和服務發現功能。
  • 其他設備發現機制。

PTP規範第7.4條要求從其傳輸中支持設備發現和枚舉。因此，PTP-IP 層應該至少實現以上這些服務中的一種。

不管使用什麼服務發現和枚舉，我們建議將設備的GUID作爲廣播包的一部分，這樣啓動端設備就能夠過濾(如果需要的話)特定的設備，並生成選擇性通知。

5.3 設備綁定和認證

認證並不是PTP-IP層的職責。如果需要身份驗證，則應該依賴於底層網絡(物理/數據鏈路層)中可用的解決方案。設備綁定可以依賴於底層網絡可用的機制或者基於PTP-IP層提供的機制在應用層實現，如下：

PTP-IP上下文中每一個設備都需要由一個可被用於設備綁定的全局唯一的標識：GUID(16字節的唯一數字)。對於這些設備，PTP-IP層提供了一個允許啓動器設備和響應端設備互相交換GUID的機制。這進而允許應用層實現設備級訪問控制(例如，一個新設備到達並被網絡發現，該設備只能接受來自已知啓動器設備的的選擇性連接，或者只能啓動到已知響應端設備的連接)。

無論使用什麼服務發現和枚舉方法，都建議將設備的GUID作爲廣播包的一部分，這樣啓動端設備就能夠過濾(如果需要的話)特定的設備，並生成選擇性通知。

5.4 數據安全

本節不屬於PTP-IP協議的範圍。數據安全將依賴於底層網絡(物理/數據鏈路層)中可用的解決方案。

5.5 The end 😃

發表評論
所有評論
還沒有人評論，想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章

DataList的用法

blue_sky_16 2018-08-31 02:58:58

內容頁訪問母版頁的屬性及控件

blue_sky_16 2018-08-31 02:58:58

datagridview的checkbox列，當修改checkbox狀態時實時獲得其狀態值

blue_sky_16 2018-08-31 02:58:58

如何去除點擊鏈接後的虛線框

blue_sky_16 2018-08-31 02:58:58

VS2010版快捷鍵

blue_sky_16 2018-08-31 02:58:58

OutputCache各參數的說明

blue_sky_16 2018-08-31 02:58:58

開始運行命令

blue_sky_16 2018-08-31 02:58:54