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

D>Я делал так:

D>1 Создавал сокет и связывал его с портом завершения В/В.
D>2 Запускал рабочий поток который в цикле "слушал" функцию GetQueuedCompletionStatus.
D>3 Вызывал WSARecv для сокета из п1.
D>4 Дальше основной поток программы засыпал до события выхода и я работал в потоке из п2.
D>5 Как только приходили данные "срабатывала" функция GetQueuedCompletionStatus, я обрабатывал все полученные данные и заново вызывал WSARecv и на начало цикла потока из п2. Ну и так до бесконечсности =)

D>Ссылки на статьи по порту я приводил в этом

Автор: Detsel
Дата: 13.09.06

посте.

D>Удачи! =)

"До бесконечности" не хорошо... от этого я и хочу избавиться. В общем пока сделал анализ хедеров HTTP-респонза. Определяю завершение
следующим образом:
1. Если есть Transfer-Encoding: chunked, то читаю до получение длины chunk = 0 (в rfc 2616 описано)
2. Если не-chunked, но есть Content-Length, то использую его
3. Иначе — "до бесконечности".

Вот только не понятны мне некоторые респонзы, если соединение идет через прокси. Нету в этом случае ни Transfer-Encoding ни Content-Length

Здравствуйте, пытаюсь написать закачку с использованием IOCompletionPort.
Вызываю WSARecv, потом — GetQueuedCompletionStatus. Как определить, что все данные уже закачались или еще нужно вызывать WSARecv? Если все данные уже скачались и вызвать WSARecv/GetQueuedCompletionStatus, то процесс подвисает на долгое время — не хорошо.

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

V>Здравствуйте, пытаюсь написать закачку с использованием IOCompletionPort.

Какой протокол над транспортным? FTP? HTTP?

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

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

V>>Здравствуйте, пытаюсь написать закачку с использованием IOCompletionPort.

MC>Какой протокол над транспортным? FTP? HTTP?

HTTP

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

V>Здравствуйте, пытаюсь написать закачку с использованием IOCompletionPort.
V>Вызываю WSARecv, потом — GetQueuedCompletionStatus. Как определить, что все данные уже закачались или еще нужно вызывать WSARecv? Если все данные уже скачались и вызвать WSARecv/GetQueuedCompletionStatus, то процесс подвисает на долгое время — не хорошо.

Я делал так:

1 Создавал сокет и связывал его с портом завершения В/В.
2 Запускал рабочий поток который в цикле "слушал" функцию GetQueuedCompletionStatus.
3 Вызывал WSARecv для сокета из п1.
4 Дальше основной поток программы засыпал до события выхода и я работал в потоке из п2.
5 Как только приходили данные "срабатывала" функция GetQueuedCompletionStatus, я обрабатывал все полученные данные и заново вызывал WSARecv и на начало цикла потока из п2. Ну и так до бесконечсности =)

Ссылки на статьи по порту я приводил в этом

Автор: Detsel
Дата: 13.09.06

посте.

Удачи! =)

V>"До бесконечности" не хорошо... от этого я и хочу избавиться. В общем пока сделал анализ хедеров HTTP-респонза. Определяю завершение
V>следующим образом:
V>1. Если есть Transfer-Encoding: chunked, то читаю до получение длины chunk = 0 (в rfc 2616 описано)
V>2. Если не-chunked, но есть Content-Length, то использую его
V>3. Иначе — "до бесконечности".

И это правильно ( IMHO )

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

V>Вот только не понятны мне некоторые респонзы, если соединение идет через прокси. Нету в этом случае ни Transfer-Encoding ни Content-Length

Возможно, это всякие запросы авторизации, типа 407. Или управление кешированием ( 304 ). Короче — служебные респонсы. У них может и не быть тела вовсе ( т.е ничто, закрытое CRLF ом )