PTPIP協議中文版

時間 2020-07-06

標籤 ptpip 協議中文版简体版

原文原文鏈接

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

PTP/IP (PTP over IP) 是一個經過IP鏈接,創建在 Picture Transfer Protocol (PTP) 上的傳輸層
英文原版協議下載

0 說明

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

1 PTP-IP協議簡介

1.1 目的

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

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操做事務時將會打開一個會話，而且使用響應端設備發出的一個有效響應成功結束該請求。socket

會話將在啓動器設備請求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，以下圖：

取決於事務操做自己，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層（編程接口，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同樣，PTP-IP也指望從其傳輸層得到可靠、穩定無錯誤的通訊通道，而TCP(位於TCP/IP協議棧中)正是能夠知足這些需求的天然傳輸層。TCP是一個基於流的傳輸層，它提供多個通訊通道(TCP Connection)和無錯誤的數據傳輸。

在PTP-IP中，兩個設備之間的全部通訊都經過兩個TCP鏈接(邏輯數據通道)進行：

因爲事件自己具備異步性質，事件的數據包與操做/數據事務數據包分開分別經過兩個單獨的通道傳輸。

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中的TCP鏈接應遵循上圖所示順序進行：

啓動器設備(Initiator)發起命令/數據的TCP鏈接：指定響應端設備(Responder)的IP地址和端口號，並鏈接到響應端設備(Responder)；
TCP鏈接創建成功後，啓動器設備(Initiator)當即發送一個Init Command Request包，數據包中須要包含啓動器設備(Initiator)的惟一標識(GUID和啓動器設備的用戶友好名稱)，例如：
響應端設備(Responder)程序根據實際狀況，回覆啓動器設備一個Init Command Ack包以告知啓動器設備請求成功而且能夠繼續進行鏈接；或者回復Init Fail數據包表示請求失敗，以告知啓動器設備請求訪問被拒絕，而且斷開命令/數據的TCP鏈接，同時啓動器設備接收到請求失敗的迴應後也應該斷開相應的的命令/數據鏈接。
啓動器設備(Initiator)接收到Init Command Ack包後，繼續發起一個事件的TCP鏈接：指定響應端設備(Responder)的IP地址和端口號，並鏈接到響應端設備(Responder)。注意該鏈接與第1步中的鏈接是區別開的。
一旦鏈接創建成功，啓動器設備(Initiator)當即發送一個Init Event Request包，數據包須要包含第4步驟中接收到的鏈接號(Connection Number)。響應端設備(Responder)須要根據這個鏈接號將命令/數據和事件兩個TCP鏈接關聯同一個PTP-IP鏈接和同一個PTP會話。
與步驟3相似，請求成功則回覆一個Init Event Ack包，在響應端設備(Responder)資源不足時，回覆Init Fail包告知啓動端請求失敗。
一旦啓動器設備(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節中定義的BINARY PROTOCOL VERSION。

啓動器設備的GUID和響應端設備的GUID可用於進行設備綁定。若啓動器設備的GUID的16個字節全由0xFF組成，則表示該啓動器設備是一個匿名設備，此時由響應端設備決定是否容許鏈接。更多信息參考附錄5.3。

啓動器設備的用戶友好名稱是一個以空(NULL)字符結尾的Unicode字符串。包括結尾的空字符，其最大長度位40個字節。不使用該字段時，必須使用一個空(NULL)字符填充該字段。

數據包示例：

對應地：

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鏈接，鏈接號便可被從新使用。

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

對應地：

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包數據中得到。

數據包示例：

對應地：

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

數據包示例：

對應地：

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瞭解綁定機制詳情。
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數據包。

實際該數據包結構以下：

對應地：

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]節。

實際該數據包結構以下：

對應地：

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表示在數據階段的開始並不知道數據的大小，該值的使用僅限於傳輸對象的大小未知的狀況(例如：傳輸流數據)。

數據包示例：

其中：

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：包含數據包中須要傳輸的數據。

數據包示例：

其中：

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：若是數據包中包含有數據則放在這個字段。

數據包示例：

其中：

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

數據包示例：

其中前、後四個字節分別爲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

數據包示例：

其中前、後四個字節分別爲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做爲廣播包的一部分，這樣啓動端設備就可以過濾(若是須要的話)特定的設備，並生成選擇性通知。