Здравствуйте, ononim, Вы писали:

MC>>>Здравствуйте, rkata, Вы писали:
MC>>>Посмотрите снифером, не на сервере ли задержка.
R>>Проблема в том, что это сторонний сервер и даже если там задержка я ничего не смогу с этим поделать. Уточняю сервер на всякий случай. Это сервер openstreetmap карт
O>Возможно сервер не простой, а.. сложный Например с внутренней БД и кэшем запросов, так что запрос на несуществующий ресурс (а значит не не существующий в кэше) будет порождать тормоза.
O>Кстати akamai умеет такую услугу — как бы стороннее http кэширование. IPшник куда вы стучитесь случайно не на akamai?

Попробовал юзать другие вещи для своей задачи. Получил интересные результаты. Ежели я использую URLOpenBlockingStream функцию , то скорость скачки и ответа на неудачу увеличивается в разы: для WinInet это было для 10 файлов 3 секунды и 20 секунд( первая цифра когда файлы существуют, вторая когда нет). Для новой функциональности — 500 миллисекунд и 10 — 50 милличекунд. Очень хорошо. Но я столкнулся с другой проблемой, которую я пока совсем не понимаю. В тестовом приложении( консольное, с поддержкой mfc) все прекрасно работает как я описал. А в реальном приложении ничего не изменилось — отладчик показывает, что скорость работы функции URLOpenBlockingStream такая же, как и у прежней функциональности. Есть какие-нибудь идеи? Про реальное приложение особо сказать нечего, код работающий для скачивания даю на всякий случай:

BYTE* DownloadURLToBuffer(LPCSTR lpszURL, int& dwSize)
{
CoInitialize(NULL);

BYTE* lpResult = NULL;
LPSTREAM lpStream;
if(SUCCEEDED(URLOpenBlockingStream(NULL, lpszURL, &lpStream, 0, NULL))){
STATSTG statStream;
if(SUCCEEDED(lpStream->Stat(&statStream, STATFLAG_NONAME))){
dwSize = statStream.cbSize.LowPart + 1;
lpResult = (BYTE*) malloc(dwSize);
if(lpResult){
LARGE_INTEGER liPos;
ZeroMemory(&liPos, sizeof(liPos));
ZeroMemory(lpResult, dwSize);
lpStream->Seek(liPos, STREAM_SEEK_SET, NULL);
lpStream->Read(lpResult, dwSize — 1, NULL);
}
}
lpStream->Release();
}
CoUninitialize();
return lpResult;
}