Есть функция (для простоты восприятия сокращена обработка ошибок и чистка памяти),
которая вычитывает данные из named pipe канала.
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
BOOL RecvData(LPBYTE* ppbRecvData, LPDWORD pdwRecvSize)
{
LPBYTE ptrBlob = static_cast<LPBYTE>(::malloc(64UL * 1024UL));
if (ptrBlob = NULL)
return FALSE;
DWORD dwReadBytes = 0UL; // кол-во считанных байт за последнюю итерацию
DWORD dwTotalSize = 0UL; // общий размер считанных данных, байт
DWORD dwBufferSize = 64UL * 1024UL; // размер буфера для приема данных, байт
LPBYTE pbEntry = ptrBlob; // точка записи новых данных
while (::ReadFile(m_hConnection, pbEntry, dwBufferSize, &dwReadBytes, NULL) == FALSE)
{
DWORD dwErrCode = ::GetLastError();
if (dwErrCode != ERROR_MORE_DATA)
return FALSE;
dwTotalSize += dwReadBytes;
// dwBufferSize *= 2UL; // удвоенный размер
pbEntry = static_cast<LPBYTE>(::malloc(dwTotalSize + dwBufferSize));
if (pbEntry == nullptr)
return FALSE;
::CopyMemory(pbEntry, ptrBlob, dwTotalSize);
::free(ptrBlob);
ptrBlob = pbEntry;
pbEntry = ptrBlob + dwTotalSize;
}
*pdwRecvSize = dwTotalSize + dwReadBytes;
*ppbRecvData = ptrBlob;
return TRUE;
}
Не понимаю, почему ReadFile считает что вычитала все данные, если я увеличиваю размер буфера dwBufferSize в два раза после каждой неудачной итерации (см. закоментированную строку в коде - удвоенный размер)?
Например, если поступили 200 КБ данных, то ReadFile сначала вычитывает 64КБ и возвращает FALSE, потом я предоставляю ей удвоенный буфер в 128КБ. ReadFile вычитывает, скажем, еще 70КБ. ReadFile при этом возвращает TRUE, в dwReadBytes помещает размер считанных данных меньший, чем переданный ей буфер dwBufferSize. Если сложить все что я вычитал (64 + 70 < 200), то получится что dwTotalSize меньше, чем реально было данных, которые были помещенны в канал отправителем.
Существует два финта ушами, которые решают проблему:
1. перед началом чтения вызвать функцию
PeekNamedPipe , узнать сколько данных, выделить нужный буфер сразу и считать все
2. закоментировать строку с удвоением буфера и читать данные только в буфер одинакового размера - 64КБ
Я бы всегда пользовался первым методом, т.к. не пришлось бы геморройничать с перевыделением буфера, копированием данных и прочим, но я пока не обкатал его и доверия он особо у меня не вызывает.
Второй метод меня не устраивает, т.к. при значительных объемах передаваемых данных (700 МБ и более), вычитывать их по 64КБ получается оччееееень дооооооолго.
Поэтому я и решил на каждую неудачную итерацию удваивать размер буфера, но столкнулся с тем, что система считает, что я все вычитал, хотя реально данных пришло больше, что и подтверждает
PeekNamedPipe , если ее вызвать в самом начале.
Либо я чего-то не понимаю, либо к концу рабочего дня уже начинаю тупить и не вижу ошибку в своем коде.
Есть идеи, что это может быть ?
PS
именнованный канал создан с IO буфером в 64 КБ
сервер, перед закрытием канала вызывает
FlushFileBuffers
клиент вычитывает данные после вызова
TransactNamedPipe с переданными пустыми значениями параметров (для ускорения сетевого обмена, вместо WriteFile/ReadFile).
То есть функция ничего не вычитывает сама, только выполняет отправку данных (запрос) и организует прием (ответ) без считывания данных, дальше работает моя RecvData.
Я знаю что в MSDN сказано что
TransactNamedPipe не гарантирует доставку данных свыше 64КБ, тогда почему стабильно работают два других метода ?
--------------------------------------------------------------
o(O_O)o
