PcShare2005的HTTP隧道的弊端

它的HTTP隧道是通過wininet API實(shí)現(xiàn)的

看看這段代碼：重點(diǎn)用紅色標(biāo)記

if(!m_PipeRecv.ConnectHttpServer(

   m_ServerAddr, m_ServerPort, nRecv,

   INTERNET_FLAG_PRAGMA_NOCACHE

   INTERNET_FLAG_NO_CACHE_WRITE

   INTERNET_FLAG_RELOAD))

{

   StopWork();

   return FALSE;

}

if(!HttpSendRequest(m_PipeRecv.hHttpFp , NULL , 0 , NULL, 0))

{

   StopWork();

   return FALSE;

}

if(!m_PipeSend.ConnectHttpServer(

   m_ServerAddr, m_ServerPort, nSend,

   INTERNET_FLAG_PRAGMA_NOCACHE

   INTERNET_FLAG_NO_CACHE_WRITE

   INTERNET_FLAG_RELOAD))

{

   StopWork();

   return FALSE;

}

INTERNET_BUFFERS BufferIn = {0};

    BufferIn.dwStructSize = sizeof( INTERNET_BUFFERS );

BufferIn.dwBufferTotal = 1024 * 1024 * 1024 + 973741824;

if(!HttpSendRequestEx(m_PipeSend.hHttpFp,

   &BufferIn,NULL,HSR_INITIATE,0))

{

   StopWork();

   return FALSE;

}

return TRUE;

/////////////////////////////////////////////////////////////////////////////////////////////////////////

HttpSendRequest(m_PipeRecv.hHttpFp , NULL , 0 , NULL, 0))

有個(gè)這些都是POST方式建立的連接， 所以這里POST一個(gè)0字節(jié)， 因?yàn)檫@個(gè)m_PipeRecv是用來接收數(shù)據(jù)的， 不需要發(fā)送數(shù)據(jù)， 但是他能接收多少數(shù)據(jù)則由Pcshare里的HTTP響應(yīng)頭Content-Length的數(shù)值決定， 一但大于這個(gè)數(shù)值， 通信就會(huì)斷開

HttpSendRequestEx里的HSR_INITIATE表示POST的數(shù)據(jù)， 用InternetWriteFile來發(fā)送， 這是POST大數(shù)據(jù)的方法， 前面有看到這句“BufferIn.dwBufferTotal = 1024 * 1024 * 1024 + 973741824;”， 這定義這個(gè)POST的數(shù)據(jù)大小， 這時(shí)候弊端就出來了， 如果我們遠(yuǎn)程監(jiān)控的服務(wù)端發(fā)送的數(shù)據(jù)量大于了這個(gè)數(shù)值BufferIn.dwBufferTotal， 這個(gè)連接就會(huì)斷開……

這時(shí)候我們發(fā)現(xiàn)， Content-Length和BufferIn.dwBufferTotal 都是32位的， 也就是只能傳輸4GB數(shù)據(jù)……， 超過了， 連接就會(huì)斷開……， 而PcShare2005里對(duì)這兩個(gè)數(shù)值的設(shè)置似乎還都不是最大的,當(dāng)然了一般情況下， 我們不會(huì)用掉這么多的數(shù)據(jù)量

新版的PcShare應(yīng)該是用socket模擬的HTTP協(xié)議， 拋棄了wininet API的方法吧.。 新版的也沒有強(qiáng)調(diào)是雙管道通信， 雙管道其實(shí)是迫不得已的設(shè)計(jì)， wininet建立的通信管道不能交叉接收和發(fā)送數(shù)據(jù)， 所以用兩個(gè)， 一個(gè)負(fù)責(zé)接收， 一個(gè)負(fù)責(zé)發(fā)送