介紹
Microsoft® DirectPlay® API提供給開發者開發例如遊戲或聊天客戶端的多人應用程式的工具。簡單起見，本檔案將把所有這樣的程式叫做“遊戲”。一個多人應用程式有兩個基本特徵：
兩個或多個單獨的用戶，每一個都在它們的計算機上具有一個遊戲客戶端。
網路聯接使得用戶的計算機可以與其它人通信，或許通過一個中央伺服器。
DirectPlay提供了一個額外的層，使你的遊戲和網路底層相隔。並且，你的遊戲可以非常簡單的使用DirectPlay API，並使用DirectPlay管理網路通訊。
特性
DirectPlay特性
DirectPlay提供的特性，使多人遊戲在開發中得到了很多簡化。其中包括：
1 創建和管理點對點，客戶/服務會話（Session）
2 在一個會話中管理用戶（User）和組(Group)
3 管理在不同網路平台上進行會話的成員之間傳送的訊息
4 使遊戲在大廳（Lobby）中互動
5 使用戶可以進行語音互動
這部分的文檔（Introduction To DirectPlay）高度概括了DirectPlay的功能。隨後的章節將告訴你DirectPlay的細節和如何在你的遊戲中使用DirectPlay。
DirectPlay Network Communication
Communicating with DirectPlay Objects
Creating and Managing Sessions
DirectPlay9.0新特性
DirectPlay應用程式接口（APIs）可以運行在Microsoft Windows® Powered Pocket PC 2002系統上。詳細內容請查看DirectPlay for Pocket PC 2002。
DPN_MSGID_SEND_COMPLETE訊息結構允許你利用其內部的兩個成員在短時間內進行訊息往返性質的傳輸。
DirectPlay提供一個新的網路服務層，你可以使用IDP8SimControl的方法去調試一個多樣性的網路環境(PS:我認為這裡是說在一個應用程式中同時使用多個協定) DirectPlay has a new service provider for network simulation. You can use the IDP8SimControl methods to test applications under a variety of network conditions.
DirectPlay有一個新的接口，IDirectPlay8ThreadPool,它允許你管理應用程式中的多個執行緒。
應用程式可以取消所有訊息傳送，前提是一個特殊的玩家在調用以下幾個函式中使用了DPNCANCEL_PLAYER_SENDS標誌位
IDirectPlay8Peer::CancelAsyncOperation, IDirectPlay8Server::CancelAsyncOperation, IDirectPlay8Client::CancelAsyncOperation.
玩家們可以在DPN_MSGID_CONNECT_COMPLETE訊息中接收他們的本地玩家標識符（ID）.
主機可以預防從進程枚舉中提取到被設定為DPNSESSION_NOENUMS 標誌位的DPN_APPLICATION_DESC結構。該訊息在調用IDirectPlay8Peer::Host and IDirectPlay8Server::Host時發出.
如果訊息傳送到一個沒有任務玩家的組中，它將馬上返回DPNSUCCESS_NOPLAYERSINGROUP以替代了原來的DPNERR_GENERIC.
信息包的簽名可用在所有DirectPlay通信上。
在調用以下幾個方法時，將標誌位設定為DPNCLOSE_IMMEDIATE，那么該應用程式可以被立即關閉。
IDirectPlay8Peer::Close,
IDirectPlay8Client::Close,
IDirectPlay8Server::Close.
DirectPlay 9.0 增強了反向連線欺騙的防禦措施
在以下方法中使用DPNINITIALIZE_HINT_LANSESSION 標誌位初始化 IDirectPlay8Peer::Initialize,
IDirectPlay8Client::Initialize,
IDirectPlay8Server::Initialize.
在調用傳送信息的函式時，信息包是可以被連線合併的。只要在以下函式中設定DPNSEND_COALESCE標誌位
IDirectPlay8Peer::SendTo,
IDirectPlay8Client::Send,
IDirectPlay8Server::SendTo.
應用程式可以利用DPN_CAPS_EX結構對DirectPlay的協定進行調整。適用函式：IDirectPlay8Peer::GetCaps,IDirectPlay8Client::GetCaps,
IDirectPlay8Server::GetCaps,IDirectPlay8Peer::SetCaps,
IDirectPlay8Client::SetCaps,IDirectPlay8Server::SetCaps.
當一個組被加入到DPNMSG_CREATE_GROUP結構中，就會擁有上下關聯的值。
如果在調用IDirectPlay8Peer::Host或者 IDirectPlay8Server::Host方法時，沒有在DPN_APPLICATION_DESC結構中設定DPNSESSION_NODPNSVR標誌位，並且沒有運行dpnsvr.exe，那么創建主機的行為將會出錯並返回DPNERR_DPNSVRNOTAVAILABLE.
Less reliable connections should now perform better with improved DirectPlay protocol behavior.
Network Address Translation (NAT) support has improved. This includes the new IDirectPlay8NATResolver interface, which allows you to create a NAT resolver application.
DirectPlay now supports Internet Protocol (IP) v6.
網路通訊
DirectPlay點對點布局
一個點對點遊戲由單獨的玩家計算機組成，用網路連線進行連線。示意，一個四玩家點對點遊戲布局看起來是這樣：
Gameplay通過具有每一用戶的遊戲客戶端與其它用戶客戶端直接通信進行控制。例如，當一個用戶移動，這一遊戲客戶端必須傳送三條更新訊息，每一條傳送到每一個其它用戶計算機。
一個點對點遊戲通常被組織和載入於一個用戶計算機上的大廳客戶端程式。大頂客戶端能夠組織一個會話有兩個基本方法：
大廳客戶端與其它潛在用戶的大廳客戶端直接進行通信。這一方案能被用於，例如，組織一個用戶在同一區域網路子網中的遊戲。
大廳客戶工作於一個遠程計算機上的大廳伺服器程式的聯接。這是基於網際網路遊戲通常的組織方法。
一旦一個會話被設定好和啟動，大部分或所有訊息將是用戶到用戶的。如果一個大廳伺服器被關聯，它將僅僅控制這樣的工作，比如當一個玩家離開遊戲時更新會話成員列表，或者允許新的用戶進入會話的請求。否則，伺服器居於後台，並且特定情況下甚至不知道大部分正發出的訊息。
因為伺服器端或者是不存在的或者至少不直接與遊戲進行有關，一個用戶被設計為遊戲主機。它們負責管理後勤的細節，如把新玩家帶入正在進行的會話。
點對點遊戲具有簡單的優點。所有所需是一個招集玩家的遊戲客戶端，通過管理一個會話。點對點布局的主要缺點是數量性。隨著用戶數量增加，訊息數量需要幾何級的增長。用戶數的最大值依賴於遊戲和網路頻寬，但是特定為不超過20-30。
DirectPlay網路通訊
協定提供了極其適用多用戶遊戲的大量特徵：
·可靠及不可靠的訊息傳遞。可靠訊息將一直重發直到對方接收；
·連續及不連續的訊息分發。連續訊息會以傳送時的順序達到目的端；
·訊息分塊及重組。如果訊息大小超過了網路傳輸能力，DirectPlay會自動把這些訊息分塊（傳輸）並重組；
·擁塞控制。DirectPlay可以自動“扼殺”Outgoing的訊息以使得目標（程式）可以（及時）處理。
（以上兩條，其實就是解決兩個問題，訊息的大小，及單位時間內可以傳送訊息的個數）
·傳送優先權，以確保重要訊息先傳送。DirectPlay可以制定三種級別低（low）、中（medium）、高（high）。high優先權的訊息在輸出佇列的前端，然後依次是medium及low優先權的訊息。
DirectPlay網路能力的核心是DirectPlay協定。這一傳輸層協定完全兼容DirectPlay8，現在並且用於所有訊息。DirectPlay協定關注於全你從傳送程式到接收程式傳送數據更簡單，不需為兩者間發生了什麼犯愁。這一協定提供了一定數量的特性，以供應多人遊戲的需求，包括：
訊息的可靠和不可靠傳輸。可靠訊息將被重新傳輸直到接收程式收到它們。你可以分配傳輸類型為message-by-message。
訊息的連續和不連續傳輸。連續訊息將以它們發出時的順序傳送的接收程式。
訊息的分裂與組裝。如果訊息尺寸超過特定網路的能力，DirectPlay自動分裂組裝訊息。
阻塞控制。DirectPlay自動扼殺你發出的訊息到一個接收程式可以控制的極別。這一特性防止你因大最接收程式不能處理的訊息所造成的訊息泛濫。
傳輸優先權。為了保證最重要的訊息首先被發出。DirectPlay允許你指定訊息為低、中、高優先權。高優先權的訊息被傳送到輸出佇列的最前面，其後是中、低優先權訊息。
訊息逾時設定。為了防止送出的訊息佇列被很多當前的訊息延時的訊息阻塞，DirectPlay允許你為所有訊息設定一個逾時值。當一個訊息逾時時，它被從發出訊息佇列（outgoing message queue）刪除，不管它發沒發出。
DirectPlay 地址
為了能傳遞訊息，多人遊戲中，每個參與者都必須擁有一個唯一（可識別的）地址。
地址可能會參照應用程式所在機器（設備地址）或者應用程式需要通信的機器（主機地址）而確定。
DirectPlay地址的形式同URL串，由scheme、scheme分隔設定及數據串組成：
為了傳輸訊息，每一個多人遊戲中的參與者必須具有一個唯一的地址。地址能涉及你的應用程式運行於其上的計算機（設備地址device address）或都你的應用程式需要通信的計算機（主機地址host address）兩者。
DirectPlay地址是URL字元串格式。這些字元串由一個scheme(方案)、scheme separator(方案分離器)和數據字元串組成，具有下面通用的格式。
x-directplay:/[data string]
數據字元串包括不同的元素，以指定使傳送者和接收者兩者間能夠發生通信所需要的任何東西，覆蓋多種不同的網路連線類型。
在使用方面，URL字元串被傳遞到DirectPlay API方法或從DirectPlay API方法傳遞的DirectPlay地址對象所包含。你具有直接操作URL字元串或使用由地址對象暴露的方法以運算元據字元串分離出的每一個元素的選項。
與DirectPlay對象通信
簡介
DirectPlay包括一個COM對象集。每個對象暴露了一個或多個使你能控制DirectPlay不同方面的一個或多個接口。比如，DirectPlay點（peer）對象(CLSID_DirectPlay8Peer)，就是負責管理點對點遊戲的。
你通過調用DirectPlay對象接口所暴露的方法來和它通訊。比如，為了在點對點遊戲給其它用戶傳送數據，你將調用IDirectPlay8Peer::SendTo方法傳送一條訊息。DirectPlay然後會在它的接收端處理接收訊息的工作。
DirectPlay通過一個或多個callback functions（回調函式）與你的應用程式進行通信這些函式和windows程式使用的回調函式相似。你的應用程式初始化期間執行這些callback function並傳遞一個這個函式的指針。當DirectPlay需要與你的程式通訊時，它調用callback function，並且傳遞兩個重要信息：
1 一個表明訊息類別的訊息標識(ID)。
2 一個數據塊指針，代表一個結構體，提供任何需要的細節。
示例
例如：
HRESULT WINAPI DirectPlayMessageHandler( PVOID pvUserContext, DWORD dwMessageId,
PVOID pMsgBuffer)
{return S_OK;}
比如，當一個傳送上面的信息的訊息到目標，目標程式的callback function將接收到一條具有DPNMSGID_RECEIVE訊息ID的訊息，指示一條訊息已經被其它用戶收到。相伴的結構體包括了數據。
因為大多數的DirectPlay訊息是多執行緒的，其中關鍵就是callback function如何被恰當的執行。
DirectPlay創建和管理會話
一個遊戲會話是一個特定的多人遊戲的實例。一個會話具有兩個或多個用戶同時遊戲，每個在他或她的計算機上具有同樣的遊戲客戶端。一個玩家（player）是一個在遊戲中自身的實體，並被特定遊戲所定義。一個用戶可能在一個遊戲中具有不只一個的玩家角色。然而，遊戲應用程式必須自己管理這些玩家，用對於每一個玩家單獨的DirectPlay接口或對象。
創建會話的第一步就是集中一組用戶。有兩種方式：
1 大多數遊戲會話都被一個運行在遠程計算機上大廳程式（lobby application）所管理。這種方式被用於大多數基於Internet的遊戲。
2、也可以通過單獨的用戶計算機與其它人的進行通信來管理遊戲。這一方式被限定於一組所有潛在用戶都在同一個區域網路中的情況下。
一旦會話被建立，遊戲就被啟動並且遊戲玩家開始遊戲。遊戲進行中，玩家可能離開會話或者新的玩家加入。細節取決於特定的遊戲。
在多人遊戲中，每一用戶的用戶界面（user interface (UI)）能被會話中的所有其它用戶所同步。管理多玩家會話因而需要一個連續的從其它用戶發出或到達其它用戶的訊息流。例如，每次一個玩家移動，一條訊息必須被傳送以在這一會話中的所有其它遊戲客戶端更新這一玩家的位置。DirectPlay的核心就是這一部分的API支持在所有在一個會話中的所有計算機間高效靈活的訊息機制。
有兩種基本的一個會話訊息機制布局（topology）的結構的方法：一種是點對點，一種是客戶/服務模式（peer-to-peer and client/server）。兩種布局都有它們的優點和限制，因而你將需要評估哪一種更適合你的遊戲。
