我把

在實(shí)現(xiàn)過(guò)程中session被做成了一個(gè)SyncDriver， 可以給actor發(fā)信但是沒(méi)有回調(diào)機(jī)制， 當(dāng)session發(fā)出一個(gè)message后它需要調(diào)用Wait()等待actor通知它已經(jīng)收到這個(gè)消息（通過(guò)actor回發(fā)一個(gè)MPK_OK）。由于session工作在ASIO的事件循環(huán)中， 所有的session都被這一個(gè)thread來(lái)驅(qū)動(dòng)， 所以如果每次發(fā)出一個(gè)messge到actor都需要進(jìn)行一次等待， 通訊thread的效率必然很差。我們需要communication thread不斷讀取網(wǎng)絡(luò)層消息并轉(zhuǎn)發(fā)給對(duì)應(yīng)actor，并且不需要等待actor的回復(fù)。

我目前的想法是在session中注冊(cè)一個(gè)actor的靜態(tài)成員函數(shù)， 既然是static member function那么就可以保證不接觸到actor的內(nèi)部status， 僅僅每次收到一個(gè)package header時(shí)候這個(gè)static memeber function決定繼續(xù)讀取多少字節(jié)的package body。zero or non-zero， 等到讀取成功后再一次性打包成一個(gè)message發(fā)給對(duì)應(yīng)的actor。

這個(gè)package包含了1. package header， 2. package body。header是固定的1byte， body是變長(zhǎng)buffer，這個(gè)buffer通過(guò)全局memory pool進(jìn)行分配。當(dāng)actor收到這個(gè)message后（MPK_NET）， 處理對(duì)應(yīng)的package然后釋放掉package body。由于申請(qǐng)body buffer在ASIO時(shí)間循環(huán)thread中， 釋放body buffer在actor message thread中， 所以需要設(shè)置memory pool為多線程enabled模式。

這里有個(gè)一假設(shè)， 網(wǎng)絡(luò)層傳入的package的header和body長(zhǎng)度不依賴于actor當(dāng)前狀態(tài)。因?yàn)樽?cè)到session中的package header回調(diào)是static的， 無(wú)法獲取actor的狀態(tài)， 并且actor model也不允許session直接獲取actor的internal status。這個(gè)假設(shè)是合理的。目前的邏輯如下：

1. actor擁有session的pointer， 并且在actor的生命周期內(nèi)session保證valid。

2. 初始化后session先和monoserver交互， 等成功登陸后monoserver創(chuàng)建player（actor）， 然后把session指針傳給player， 把player地址傳給session。

3. session收到header后通過(guò)player注冊(cè)的static memeber function決定如何接受network data stream并打包成一個(gè)package， 這個(gè)過(guò)程中如果需要buffer就通過(guò)global memory pool申請(qǐng)。

4. session發(fā)送這個(gè)package（header， body pointer)到player， 然后接受下一個(gè)header。。。

5. player收到這個(gè)message， 處理， 釋放body pointer回global memory pool。

整個(gè)過(guò)程中session沒(méi)有等待actor回復(fù)， actor收到的總是一個(gè)完整的package。