Привет всем.
У меня такая проблема. Работая с некоторым сервером, я загружаю с него необходимые мне файлы. В некоторых ситуациях запрашиваемого файла может не быть на сервере. Как результат, естественно я в ответ получаю ошибку 404 ошибку ( HTTP_STATUS_NOT_FOUND, object not found). Но ответ этот приходит слишком медленно, и как раз это меня не удовлетворяет — потому что я могу запросить у сервера несколько десятков файлов). Ислозьзую я для своей задачи WinInet, основная задержка происходит на вызове HttpSendRequest. Пробовал использовать вместо "GET" запроса "HEAD" — не помогло, так же работает. Каждая задержка — порядка секунды, но если я спрашиваю у сервера о нескольких десятках файлов — уже время порядочное получается. Есть способ узнать существует файл на сервере или нет быстрее? Ответ типа попробуй оптимизировать колличество запросов от своего клиента и тому подобное — не интересует.

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

Посмотрите снифером, не на сервере ли задержка.

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

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

MC>Посмотрите снифером, не на сервере ли задержка.

Проблема в том, что это сторонний сервер и даже если там задержка я ничего не смогу с этим поделать. Уточняю сервер на всякий случай. Это сервер openstreetmap карт

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

R>У меня такая проблема. Работая с некоторым сервером, я загружаю с него необходимые мне файлы. В некоторых ситуациях запрашиваемого файла может не быть на сервере. Как результат, естественно я в ответ получаю ошибку 404 ошибку ( HTTP_STATUS_NOT_FOUND, object not found). Но ответ этот приходит слишком медленно, и как раз это меня не удовлетворяет — потому что я могу запросить у сервера несколько десятков файлов).

Как тут уже сказали, необходимо проверить, не на стороне ли сервера задержка. Если там — то с задержкой ничего не сделать. Но можно запрашивать данные в несколько потоков. Браузеры придерживаются соглашения "не больше двух подключений к серверу", и если запрашивать данные в 10 потоков — как бы сервер не обидеть, но 2-4 потока — это нормально.

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

Здравствуйте, 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;
}

К сожалениею мое предыдущее сообщение о URLOpenBlockingStream оказалось враньем — была ошибка в коде. На самом деле нету никакого выигрыша, работает с одинаковой скоростью...