經過一段時間的學習，基於以太網交換機的TRDP PD開發調試結果已經正常了，故此，記錄一下。
TRDP基於生產者、消費者模型。
TRDP PD 通信模式有兩種，push和pull。在這兩種模式中，網絡設備又可以分爲三種角色：publisher、subscriber、requester.
publisher是數據的提供者，在push和pull模式中負責發送註冊的comId的數據，即所謂的生產者；
subscriber是數據的接受者，這push和pull模式中負責接收註冊的comid的數據，即所謂的消費者；
requester是數據的請求者，在pull模式中負責對publisher發起請求，pd-pdu的頭部中會帶有相應的reply IP和reply comID，如果頭部中沒有指定需要reply的IP和comID，則publisher會把接收到的報文的源作爲reply的目的給發送回去。
在pull模式中，requester也可以是subscriber。
/**************************************************************************************************************************************************/
tlc_ 提供了trdp的通用接口，因此在驗證功能時非常好用。
//trdp 協議棧初始化
//初始化打印函數和VOS的內存管理
EXT_DECL TRDP_ERR_T tlc_init (
const TRDP_PRINT_DBG_T pPrintDebugString,
void *pRefCon,
const TRDP_MEM_CONFIG_T *pMemConfig);
//打開一個trdp 協議棧session入口,這裏主要是進行協議棧的配置，返回pAppHandle，這個至關重要
EXT_DECL TRDP_ERR_T tlc_openSession (
TRDP_APP_SESSION_T *pAppHandle,
TRDP_IP_ADDR_T ownIpAddr,
TRDP_IP_ADDR_T leaderIpAddr,
const TRDP_MARSHALL_CONFIG_T *pMarshall,
const TRDP_PD_CONFIG_T *pPdDefault,
const TRDP_MD_CONFIG_T *pMdDefault,
const TRDP_PROCESS_CONFIG_T *pProcessConfig);
1、PD publisher驗證
數據的發佈者需要先準備發送的數據，將comID、destip、timeout等信息作爲一個實體添加到協議棧的發送隊列中
EXT_DECL TRDP_ERR_T tlp_publish (
TRDP_APP_SESSION_T appHandle,
TRDP_PUB_T *pPubHandle,
const void *pUserRef,
TRDP_PD_CALLBACK_T pfCbFunction,
UINT32 comId,
UINT32 etbTopoCnt,
UINT32 opTrnTopoCnt,
TRDP_IP_ADDR_T srcIpAddr,
TRDP_IP_ADDR_T destIpAddr,
UINT32 interval,
UINT32 redId,
TRDP_FLAGS_T pktFlags,
const TRDP_SEND_PARAM_T *pSendParam,
const UINT8 *pData,
UINT32 dataSize);
TRDP_ERR_T tlp_put (
TRDP_APP_SESSION_T appHandle,
TRDP_PUB_T pubHandle,
const UINT8 *pData,
UINT32 dataSize);
這裏的每一個實體都是不重複的。因此，在週期推送數據的過程中，trdp 會 依次遍歷自己的發送隊列，將信息發送給目的地址。
這裏的tlp_put()的功能就是將所需要發送的信息作爲pd-pdu的dataset組織好數據報，放入發送隊列中相應的節點存儲。利用linux的select()函數來進行非阻塞的等待，週期性推送timeout的數據，即馬上要發送的數據。
2、subscriber驗證
subscriber是數據的接受者，需要先註冊接收的信息，包含了源IP範圍、comID，然後調用tlp_subscribe來註冊到協議棧session的接收隊列中。
EXT_DECL TRDP_ERR_T tlp_subscribe (
TRDP_APP_SESSION_T appHandle,
TRDP_SUB_T *pSubHandle,
const void *pUserRef,
TRDP_PD_CALLBACK_T pfCbFunction,
UINT32 comId,
UINT32 etbTopoCnt,
UINT32 opTrnTopoCnt,
TRDP_IP_ADDR_T srcIpAddr1,
TRDP_IP_ADDR_T srcIpAddr2,
TRDP_IP_ADDR_T destIpAddr,
TRDP_FLAGS_T pktFlags,
UINT32 timeout,
TRDP_TO_BEHAVIOR_T toBehavior)
協議棧根據timeout時間來接收綁定的socket數據，對接收到的數據進行校驗，例如CRC、TOPOCOUNT、SRCIP、COMID。根據pdu的msgType來判斷是否是Pr類型的數據，pr類型也就是請求包，收到這樣的包需要查看發送隊列是否存在comid相同的節點，如果存在，需要馬上將數據作爲msgType==Pp推送給reply IP，並且通知trdp user層（打印函數）。
3、requester驗證
請求數據和publisher很相似，不過這裏是調用了tlp_request來進行msgType==Pr數據的準備。
EXT_DECL TRDP_ERR_T tlp_request (
TRDP_APP_SESSION_T appHandle,
TRDP_SUB_T subHandle,
UINT32 comId,
UINT32 etbTopoCnt,
UINT32 opTrnTopoCnt,
TRDP_IP_ADDR_T srcIpAddr,
TRDP_IP_ADDR_T destIpAddr,
UINT32 redId,
TRDP_FLAGS_T pktFlags,
const TRDP_SEND_PARAM_T *pSendParam,
const UINT8 *pData,
UINT32 dataSize,
UINT32 replyComId,
TRDP_IP_ADDR_T replyIpAddr)
tlp_request會生成一個新的實體，放入trdp session的發送隊列中去。如果收到相應的Pp報文，則需要通知trdp user層。
/***********************************************************************************************************************************************/
PD數據的推拉模式，源碼中已經寫的比較獨立和清晰，需要關注的點是和操作系統的對接，主要也就是socket編程。PD使用的是UDP協議，IANA 分配的port爲17224，iec61375-2-3中規定的是20548。在UDP對接中，不同的系統的難度是不一樣的，源碼可以再Windows系統和linux系統直接生成相應的執行文件，適配網絡平臺則需要慢慢調試，驗證相應的收發功能。