Утилита синхронизации файлов с HTTP в локальную папку

[Adam Smith]

Очевидно тем, что меня посылают Искать ответ. Ведь в поисках ответов и за "прокачкой" я пришел сюда.
Ладно бы я не туда пришел, но именно тут дают даже готовые решения и даже тем, кто никогда не будет вникать в то, что получил.
Недоволен, что по каким-то сверхъестественным причинам ко мне такое отношение оказалось неприменимо. Подозреваю виновата география и история.

Из всего, что я прочитал в т.ч. и на этом сайте, я понял, что на освоение вечной темы(многопоточности) и попытки реализовать это уйдёт столько времени, что имеет смысл забить на это.
Блин, даже запущенная в OLE1 прога с бесконечным циклом не вешает основное приложение.
Имеет смысл копать туда. То, что мне нужно, быстрее всего реализуется на wscript.

У кого-нибудь получалось работать с ActiveX DLL без её объявления, а только с помощью манифестов?
По этому методу: https://msdn.microsoft.com/en-us/library/ms973913.aspx#rfacomwalk_topic6

[Proxy]

ремарка оффтоп:
Adam Smith, ведь ты ничего конкретного даже не спросил. На что готовое решение?
Сначала ты идешь по какому-то странному пути (правда не знаю, почему Хакер в этот раз не стремится корректировать в привычной манере, возможно даже у него не сложилась полная картина), потом зачем-то говоришь о каком-то случае, когда человеку помогли исходником и приводишь какие-то аналогии.

Тут много всяких вещей происходило за годы существования. Совместные проекты зарождались, мозголомные задачи решались и многое другое. Но никто никому ничего не должен. Заинтересовало — участвуют, не заинтересовало — проходят мимо.
В твоем же случае во-первых, из тех крупиц адекватно изложенного материала, складывается впечатление примитивной задачи, с которой каждый сталкивался (где-то даже валялся мой ужасный информер, который брал погоду с gismeteo по http, парсил xml и выводил), во-вторых ты взял какой-то большой вектор, но не обращаешь внимания на детали. Начни что-то делать — помогут. Если задача представляется решаемой, не значит, что она уже решена.

И для чего вообще кто-то будет выкладывать сюда исходники, если всё это находится поисковыми машинами на раз-два?

Ведь в поисках ответов и за "прокачкой" я пришел сюда.

Выглядит иначе.

[Хакер]

Подозреваю виновата география и история.

Какая феноменальная чушь.

Я вообще-то люблю конкретные вопросы. Даже висит наверху красная плашка, в которой говорится, что темы, в которых авторы рассказывают, что им на этот раз поручили сделать, но ничего конкретного не спрашивают — будут сноситься.

В той теме человек задал конкретный вопрос: почему один алгоритм хуже другого и как улучшить ситуацию. Конкретный вопрос получил конкретный ответ: что медленность из-за огромного числа проверок повторений, а улучшить ситуацией можно сменой организации. В качестве примера я заикнулся о примере с деревом, а автор попросил пример сделать.

Другое дело, когда сообщения представляют собой перечисление в спонтанном порядке каких-то предположений, домыслов и идей, да ещё и с отсылками к чьим-то примерам. Первый пост имел настолько запутанный слог, что я вообще ничего не понял.

С такими постами и с такой манерой ведения дискусии я просто не знаю что делать. Предугадывать все возможные спрятанные между строк вопросы я тоже не буду: у меня настолько богатая фантазия, что я таких вопросов угадаю тысячу — разных. И давать ответы и создавать примеры на каждый потенциальный вопрос, который теоретически мог где-то там на другой стороне возникнуть, у меня при таком подходе не хватит жизни.

Поэтому делаем вдох и слушаем правило.

Конкретные чёткие вопросы — конкретные чёткие ответы.

[Adam Smith]

Непонятное предположение с первого поста, по сути:

Код: Выделить всё

Я написал класс для получения списка URL'ов с HTTP серверов, но думаю может лучше выбросить позднее связывание с IE и написать абсолютно всё на api? Что подскажете?

Следующий мой домысел:

Код: Выделить всё

От самописной реализации меня отталкивает необходимость собирать фрагменты "chunks".
И наоборот притягивает возможность легко узнать дату, размер файла перед скачиванием.
Может кто уже писал что-то практическое с обменом по протоколу HTTP, и что подскажет?

Далее:
Благодаря предложению использовать wget/fetch я решил написать всё сам и желательно так, чтобы работало на всей линейке ОС Windows, например начиная с 98.
Накопал решения, простейшие на мой взгляд. Выложил пару кусков проверенно рабочего кода.

Следующая моя идея с отсылкой к чьим-то примерам, цитирую:

Код: Выделить всё

Чтобы программа не подлагивала при торможениях процесса,
хочу сделать 2 отдельных процесса, интерфейсный и рабочий.
Посоветуете из вашего опыта, [b]как реализовать обмен между процессами?[/b]
Первыми мне в голову лезут простейшие костыли на api PostMessage
Дочерний процесс в командной строке получает hWnd тексбокса
и отправляет в тот текстбокс hWnd своего текстбокса.
Теперь оба процесса могут слать PostMessage друг другу :lol:
Советуют аж в бородатом году http://www.codeproject.com/Articles/3815/Inter-process-communication-using-registered-messa

Далее:
Благодаря совету продолжил копать в указанном направлении. Впоследствии с уточняющими вопросами и ответами в течении двух дней.

Пока я не спросил по сути:

Код: Выделить всё

Искать ответ в статьях Trik'а или дадите (другую) ссылку?

Тут я наверное наступил на любимую мозоль. Почему? Потому, что ДО этого был дельный разговор, а ПОСЛЕ философский.
Больше не затрагиваю философскую тему многопоточности, буквально, не обижайтесь, тут нет никакого скрытого смысла.
Я нашел на форумах готовые классы, они работают и позволяют "отвязать" потоки друг от друга, а остальное напишу сам.

[Adam Smith]

Proxy, я могу заняться цитированием каждого "непонятного" момента и попытаться объяснить, но уверен, всё и так понятно.
Количество моих вопросов порой даже с предположениями и вариантами ответов вполне объясняет, зачем я сюда вернулся.

Продолжали бы по стариковски подсказывать, как вы в былые годы решали такие, нынче уже банальные задачи. Так и подсказки жалко?
И никто не подсказал мне, что в GET запросе достаточно будет указать протокол 1.0, и не нашлось исходников для борьбы с chunked. А?

Я тоже получал из биллинга XML, никакого chunked, парсить не нужно, есть надежные библиотеки. Кажется не велика наука когда всё сделал.
В интернетах конечно есть, но говнокода больше, чем толковых решений. Так быстро их не найдешь. Только опытные люди помнят и делятся.

Контекст был понятен с моего первого поста, не надо всё с ног на голову переворачивать, уж точно я не бОльший смутьян чем ты.
А вот твой пост как раз выглядит как попытка замутить ну хоть какой-то флэйм на давно остывшем месте))

[Proxy]

Продолжали бы по стариковски подсказывать, как вы в былые годы решали такие, нынче уже банальные задачи.

Тогда эта задача не была менее банальна, нежели сейчас.

И никто не подсказал мне, что в GET запросе достаточно будет указать протокол 1.0, и не нашлось исходников для борьбы с chunked. А?

Некорректный подход. Верно, что не подсказали.

А вот твой пост как раз выглядит как попытка замутить ну хоть какой-то флэйм на давно остывшем месте

Необоснованные домыслы.

Между тем завершался 2015 год, Apache, nginx, IIS и практически все веб-обозреватели поддерживали http/2. Но кого-то ещё особенности 1.1 удивляли.

[Adam Smith]

кого же и где же это они удивляли? интересно. На кого этот прозрачный намек без малейшей попытки пофлэймить?

Кто-то продолжает на vb6 кодить, но тем не менее зачем-то перечисляются прошедший год и некие современные сервера.
Кстати да, я в курсе, что весь интернет движется в сторону отказа от небезопасных соединений. Уверен, и вы тоже в курсе.

[alibek]

что весь интернет движется в сторону отказа от небезопасных соединений

Я думаю, что эта тенденция долго не продлится.
1) Это не соответствует идеям WWW. HTTPS должен использоваться только там, где он действительно нужен, в остальных случаях нужно использовать HTTP.
2) HTTPS означает, что про кеширование нужно забыть. И про проксирование, с рядом оговорок.
3) Это бессмысленный и значительный рост нагрузки на веб-сервера.
4) Мысль о том, что HTTPS позволит уйти из под контроля государства (посещение заблокированных сайтов), кажется мне несостоятельной. Если HTTPS станет доставлять серьезные неудобства государству, его просто заблокируют. Либо обяжут центры сертификации предоставлять закрытые ключи. При этом утечки неизбежны и HTTPS будет скомпрометирован.

[Adam Smith]

Так по пунктам расписать я бы не сообразил, но согласен с каждым словом. Одно дело фича "Инкогнито" в браузерах, новое - забытое старое, "Опера-Турбо".
И совсем другая история с переводом всего трафика на SSL или даже на TLS. Это каждый хозяин будет сам решать, и взвешивать за и против такого гемороя)
Что-то я не представляю, в чём смысл отключать на серверах поддержку HTTP 1.0, которая по-умолчанию всегда есть и бывают ли вообще такие настройки.

[Proxy]

На кого этот прозрачный намек без малейшей попытки пофлэймить?

Без. Не я скатываю в оффтоп.

Кто-то продолжает на vb6 кодить, но тем не менее зачем-то перечисляются прошедший год и некие современные сервера.

Кто?

Кстати да, я в курсе, что весь интернет движется в сторону отказа от небезопасных соединений.

Летят два крокодила, один зеленый, а другой на север. Мой посыл касался исключительно chunked transfer encoding.

При этом утечки неизбежны и HTTPS будет скомпрометирован.

Уже есть опыт подмены сертификатов в СНГ. Браузер оповещает, но не всяк понимает, что это означает. Да и простого выхода всё равно не остается, проще смириться в некоторых случаях, когда https необоснованно использован.

Одно дело фича "Инкогнито" в браузерах

Да, но разве сейчас инкогнито делает что-то, кроме как изолирует профиль и не сохраняет историю и куки? Прокси не задействуется.
Опера-Турбо стала тоже шакалить. Вижу, как Опера в турбо продолжает соединяться напрямую в некоторых случаях, без какого-либо уведомления. Т.е. во всём этом я не усматриваю ничего, как-либо связанного с безопасностью.

Что-то я не представляю, в чём смысл отключать на серверах поддержку HTTP 1.0, которая по-умолчанию всегда есть и бывают ли вообще такие настройки.

Есть, однако тогда поисковики не смогут индексировать, они заходят по HTTP 1.0 часто. Но в спецификации чистого http 1.0 многого нет, без чего сегодня сложно обойтись. Все эти фичи enhanced. Chunked transfer encoding упомянутый в т.ч: в 1.0 поддержку тоже можно встретить, но в RFC он вошел с версии 1.1. Принудительное требование наличия hostname в запросе опять же в чистом 1.0 не предусмотрено, без этого более 1 сайта на одном сетевом адресе не захостить (цивильными методами, во всяком случае). Многие моменты в 1.0 не затронуты, поэтому реализуются на усмотрение разработчика (все ориентируются на популярные решения).

Однако всё это не говорит в пользу того, что использовать 1.0 — хорошая идея.

[Adam Smith]

Тогда эта задача не была менее банальна, нежели сейчас.

Там был ещё один вопрос в конце, такой незаметный и неудобный своей конкретностью.

Да, блин, могу я склеивать эти куски, протокол 1.1 даже по-русски в вики расписан понятно.
Считаете, мне нужно это сделать? Так и напишите, чего философствовать вокруг банального?

Есть, однако тогда поисковики не смогут индексировать, они заходят по HTTP 1.0 часто. (все ориентируются на популярные решения).
Однако всё это не говорит в пользу того, что использовать 1.0 — хорошая идея.

Выш прям фанаты конкретики, так и написали бы:
"Врубись, первый же заголовок куска даёт наводку на конец первого и начало следующего куска, а там снова заголовок, и так до заголовка с цифрой 0 !!!".

Куски не имеют никакого отношения к событию сокета DataArrival, вообще равнофигственно, т.е. по любому ждать закрытия коннекта и вырезать их все.
Есть пример, когда chunked transfer нарезая теряет байты в конце куска, да вот представьте. Лучше попросить сервер не разбивать страницу на куски?
Или лучше клеить, то, что тебе настрогали? Без философских вздохов обоснуй, почему эта популярная для индексирования идея не годится для задачи?

[Qwertiy]

И никто не подсказал мне, что в GET запросе достаточно будет указать протокол 1.0, и не нашлось исходников для борьбы с chunked. А?

А почему сервер должен поддерживать 1.0? И в чём вообще проблема с chunked? Это вопрос, как сделать конкатенацию двух массивов?

Чтобы программа не подлагивала при торможениях процесса, хочу сделать 2 отдельных процесса, интерфейсный и рабочий.

Зачем два процесса, если достаточно двух потоков?
А может и одного. Разве api асинхронного ввода-вывода не может работать с сетью?

[Adam Smith]

А почему сервер должен поддерживать 1.0?

Для начала никто никому ничего не должен. Но например для ответа, что предпочтителен 1.1. А ещё знатоки говорят, что поисковые боты часто по 1.0 ходят.

И в чём вообще проблема с chunked? Это вопрос, как сделать конкатенацию двух массивов?

:lol: Вправду похоже, что проблема со слиянием? В моём случае вообще строки, нет проблем с кусками и 1.0 я использую для получения списка файлов.

Я пойму если сервер не выдаст контент на нужном мне языке и в нужной кодировке, сервера не для меня ставили, они могут быть вообще китайские.
Но объясните, я ДОЛЖЕН использовать протокол 1.1 потому, что сервер его предпочитает? Когда будет нужен 1.1 использую, но та задача проще с 1.0.
Серверу может быть предпочтительно что угодно, хоть DB-Link, мне на минуточку кажется, что в нашей реальности сервера для клиентов, а не наоборот.

Зачем два процесса, если достаточно двух потоков? А может и одного. Разве api асинхронного ввода-вывода не может работать с сетью?

Как может так и работает, асинхронность не спасает от подтормаживания в момент коннекта или передачи запроса при медленном канале.
Я почему-то уверен, что один поток неизбежно будет подлагивать, тем более дальше по программе скачивание N'ного (большого) кол-ва (больших) файлов.

[Хакер]

В моём случае вообще строки

Ты не должен использовать строки. Ты должен использовать блочно-связанный список, построенный на байтовых массивах.

мне на минуточку кажется, что в нашей реальности сервера для клиентов, а не наоборот.

Ха-ха. Почитай-ка.

Как может так и работает, асинхронность не спасает от подтормаживания в момент коннекта или передачи запроса при медленном канале.
Я почему-то уверен, что один поток неизбежно будет подлагивать, тем более дальше по программе скачивание N'ного (большого) кол-ва (больших) файлов

Это чушь и паранойя. А вот что действительно правда: асинхронные API (дико глючный WinInet и более нормальный WinHTTP) не имеют механизма асинхронных уведомлений такого, чтобы дёргался именно поток-заказчик. Это будет второй горе-топик аналогичный соседнему топику про таймеры.

[Adam Smith]

Прочитал, и как я понял, было бы хорошо, чтобы моя программа работала в т.ч. и с шарами яндекса.
И потому даётся пример, показывающий, что нужно как-то подстраиваться под множество серверов.
Не понял, если поддержка серверами неких браузеров это чистая коммерция, то причём тут тема?
Тут же из обсуждения понятно, что всё дело в обмане сервера выдачей "правильного" юзер агента.
Я планирую сделать текст запроса и юзер агент изменяемым где-нибудь в настройках программы.

На счет "блочно-связанных списков", дал бы ссылку, я нашел вот Линейный однонаправленный список: https://ru.wikipedia.org/wiki/%D0%A1%D0 ... 0%BE%D0%BA
Не вижу никакого преимущества перед обычной строкой в которую сливаются все поступающие данные.
Какая-то фишка в работе с памятью? В строке мне удавалось держать файлы объемом в сотни мегабайт.

А последняя цитата и "ответ" это вообще какой-то эпик, какой я должен был из этого сделать вывод?

Уже пару раз оказывалось так, что я "почему-то" делаю неправильные выводы и преследую неверные цели. Просто напишите мне сухие выводы из всего этого, ок?
А я приму буквально, хотя и постараюсь сам понять, т.с. для прокачки своего уровня. Я пришел сюда и по-умолчанию полагаюсь на то, что плохого не советуют.

[Хакер]

Прочитал, и как я понял, было бы хорошо, чтобы моя программа работала в т.ч. и с шарами яндекса.

Если ты про мою ссылку, то вынужден с прискорбием сообщить, что с пониманием у тебя большая беда.

Мораль для тех, кто в танке: это в идеальном мире серверы для клиентов, а в реальном мире владельцы серверов очень запросто отключают любые «устаревшие штучки» по любой мало-мальской причине или вообще без неё. И то, что не всякий клиент после такого сможет поработать с сервером, в современном мире владельцев серверов не особо волнует. «Пусть качают и используют самое моднявое, современное и поддерживающее всё самое модерновое» — вот что в мыслях у владельцев современных серверов.

На счет "блочно-связанных списков", дал бы ссылку,

Да я не держу никаких ссылок ни на какие статьи или примеры. Если уж мне и нужна какая-то вещь, то я иду в Гугл, а Гугл есть у всех в равной степени.
То, что ты нашёл, касается просто связного списка, а тут, очевидно, речь идёт о таком, где элемент цепочки — это блок каких-то данных.

Не вижу никакого преимущества перед обычной строкой в которую сливаются все поступающие данные.

Это не значит, что их нет.

Не бывает понятия «обычная строка». Почитай-ка это, чтобы вымыть инфантильный взгляд на вещи из головы.
Почитал? А теперь слушай. У списка блоков нет никаких преимуществ. Это естественный способ организации данных в такой ситуации.

Зато у хранения в строке есть два диких недостатка:
1) Каждое приклеивание маленького кусочка к большой строке потенциально вынуждает выделить другой участок памяти, а это вынуждает копировать всю старую строку целиком из старого места в новое место. Тысяча копирований мегабайтной строки — это гигабайт впустую туда-сюда гоняемой информации.
2) VB-строки предназначены для хранения юникодных символов. Если ты будешь тупо рассматривать входящие данные как строку, то у тебя будет перерасход памяти на 100 процентов (то есть в два раза).

А кроме диких крупных недостатков есть ещё более мелкие:
3) Это идеологически неверно и чревато.
4) Строковый пул не оптимизирован под выделение огромных строк.
5) Строковый пул меньше, чем вся теоретически и практически доступная процессу память. Кому-то память понадобится под BSTR-строку, памяти самой по себе будет навалом, но выделенеи строки обломится, потому что кто-то додумался в строковом пуле держать гигантские строки с контентом HTTP-ресурсов.

какой я должен был из этого сделать вывод?

Что мнение, что многопоточное скачивание априори хуже многопроцессного, глупое и не на чём не базируется.

[Adam Smith]

Что мнение, что многопоточное скачивание априори хуже многопроцессного, глупое и не на чём не базируется.

Чьё это мнение? Моё мнение о многопоточности сложилось из ваших статей и постов, суть в том, что надежная многопоточность в vb6 нереализуема, даже если защитить все "свои" данные, рантаймовые останутся.

По вышеописанному понятно, но в общем, сам я такого никогда не делал. В длительных циклах и для хранения файлов String использовать не буду.
И таки пишу новый класс без конкатенации строк и с протоколом 1.1, но к строкам отношусь просто, могу прям в коде в кавычках что-то написать.

[Proxy]

Да, блин, могу я склеивать эти куски, протокол 1.1 даже по-русски в вики расписан понятно.
Считаете, мне нужно это сделать?

Да.

[Хакер]

Чьё это мнение?

Того, кто писал этот текст:

Я почему-то уверен, что один поток неизбежно будет подлагивать, тем более дальше по программе скачивание N'ного (большого) кол-ва (больших) файлов.

Моё мнение о многопоточности сложилось из ваших статей и постов

Я в своих статьях и постах не писал ничего о подлагивании.

но к строкам отношусь просто, могу прям в коде в кавычках что-то написать.

Не понял я, к чему этот малопонятный пассаж был. Что за ним скрывается и радоваться или печалиться этому.

[Adam Smith]

Кол-во поступивших байт будет известно только после их получения в программу, байт массив нужно делать сразу размером 64К ??

Код: Выделить всё

Private Declare Function recv _
                Lib "ws2_32.dll" (ByVal S As Long, _
                                  ByVal buf As Any, _
                                  ByVal BufLen As Long, _
                                  ByVal flags As Long) As Long

Покажите пример, как готовить и передавать ей байт массив?

[Adam Smith]

Ошибка твоя очевидна всем, но никто не пикнет, её как-бы нет))

[Хакер]

О чьей ошибке ты говоришь?

[Adam Smith]

Чтобы программа не подлагивала при торможениях процесса, хочу сделать 2 отдельных процесса, интерфейсный и рабочий.

Зачем два процесса, если достаточно двух потоков?
А может и одного. Разве api асинхронного ввода-вывода не может работать с сетью?

Тут человек явно говорит об одном потоке, Standart EXE, повторяю, не о многопоточности.

Зачем два процесса, если достаточно двух потоков? А может и одного. Разве api асинхронного ввода-вывода не может работать с сетью?

Как может так и работает, асинхронность не спасает от подтормаживания в момент коннекта или передачи запроса при медленном канале.
Я почему-то уверен, что один поток неизбежно будет подлагивать, тем более дальше по программе скачивание N'ного (большого) кол-ва (больших) файлов.

Я отвечаю, что в однопоточном Standart EXE будут подлагивания, это не моя придумка, есть такое словечко https://ru.wikipedia.org/wiki/Лаг_(компьютерный_сленг)

Как может так и работает, асинхронность не спасает от подтормаживания в момент коннекта или передачи запроса при медленном канале.
Я почему-то уверен, что один поток неизбежно будет подлагивать, тем более дальше по программе скачивание N'ного (большого) кол-ва (больших) файлов

Это чушь и паранойя. А вот что действительно правда: асинхронные API (дико глючный WinInet и более нормальный WinHTTP) не имеют механизма асинхронных уведомлений такого, чтобы дёргался именно поток-заказчик. Это будет второй горе-топик аналогичный соседнему топику про таймеры.

Это признание моей правоты не должно было быть явным, для этого мой пост назван чушью и паранойей и поверх всё это присыпано мини-предсказанием.

какой я должен был из этого сделать вывод?

Что мнение, что многопоточное скачивание априори хуже многопроцессного, глупое и не на чём не базируется.

Тут мне присвоено глупое мнение, которого я никогда не придерживался и нигде не высказывал.

Чьё это мнение?

Того, кто писал этот текст:

Я почему-то уверен, что один поток неизбежно будет подлагивать, тем более дальше по программе скачивание N'ного (большого) кол-ва (больших) файлов.

Тут подтверждается, что это не я что-то себе придумал, а ко мне действительно приклеено какое-то глупое мнение о том, что многопоточность хуже.

Т.е. изначально я написал, что однопоточное приложение будет подтормаживать при закачке и копировании. Моё однопоточное ты подменяешь на многопоточное и выдаёшь свою глупую выдумку за моё мнение.
При этом продолжаешь дискредитировать мои попытки исправить недопонимание. Я тоже могу бездоказательно утверждать, "Ты глупо думаешь то-то и то-то", и также могу игнорить твои попытки что-то мне отвечать.

[Adam Smith]

Но я бы прежде чем писать, подумал, предстоит ли серия склеек, предстоят ли групповые склейки, есть ли смысл в обёртовании массивов в варианты и не лучше ли перейти на блочно-массивную организацию данных и вообще ничего не склеивать.

В моём случае вообще строки

Ты не должен использовать строки. Ты должен использовать блочно-связанный список, построенный на байтовых массивах.

На счет "блочно-связанных списков", дал бы ссылку,

Да я не держу никаких ссылок ни на какие статьи или примеры. Если уж мне и нужна какая-то вещь, то я иду в Гугл, а Гугл есть у всех в равной степени.
То, что ты нашёл, касается просто связного списка, а тут, очевидно, речь идёт о таком, где элемент цепочки — это блок каких-то данных.

На счёт малопонятных пассажей, гугл не понимает твоих "блочно-связанный список, построенный на байтовых массивах" и "блочно-массивную организацию данных", похоже кому-то пора прекращать острить и садиться за очередную общественно-полезную статью.

[Хакер]

Ох, тяжелый случай.

Я почему-то уверен, что один поток неизбежно будет подлагивать, тем более дальше по программе скачивание N'ного (большого) кол-ва (больших) файлов.

Вот это утверждение было тобою дано в ответ на что?

Я напомню, на что. В ответ на то, что тебе предложили вместо многопроцессного подхода использовать что-либо из двух:

• Делать несколько потоков.
• Делать один поток и использовать асинхронные API.

Ты зацепился за последнее и прокомментировал, что касательно одного потока и асинхронных API у тебя есть «почему-то уверенность», что это будет подлагивать.

Вот именно эта «почему-то уверенность», а не «моя глупая выдумка» была выдана за твоё мнение.

Это не твоё мнение?

[Adam Smith]

Классная вариативность у ситуации если аккуратно подзабыть про свои посты, которые кто-то так неудобно процитировал, и которые всегда можно не заметить.

Так что ещё раз: НЕ БУДЕТ никакой стабильности работы МП-процесса на VB6, пока потоко-специфичные данные лежат в секции данных (что вполне годится для реально-singlethreaded-программ), а не в TLS.
*******
Увы, но это не сработает. Потому что в набор потоко-специфичных данных, которым нужна изоляция, входят не только все ваши глобальные, но и ряд внутрирантаймовых переменных, о которых вы не догадываетесь. То есть какими бы чудесным и совершенным не были бы лично вы и ваш вылизанный код, который бы использовал глобальные переменные очень аккуратно, и вдумчиво бы использовал TLS там, где это надо для межпоточной изоляции, ваш проект всё равно будет падать в случайные моменты времени, потому что изоляция тех структур, которые используются «под капотом» для работы VB, не обеспечена.

Упс, снова процитировал.
Всё таки ты утверждал, что многопоточный вариант, который (ты говоришь) мне тут любезно предложили - это вообще-то не вариант. А значит остаётся второй вариант, ОДНОПОТОЧНЫЙ (Standart EXE).
И тут ты тоже утверждал, что API не имеют нормального механизма асинхронных уведомлений, цитировать не буду, ты всё равно придумаешь альтернативную версию моего мнения, того, что я хотел сказать и думал.
Яж говорю, ты продолжаешь утверждать, что твоя фантазия это и есть мои мысли, моё мнение. И в этом ты прав, даже более того, всё что тебя окружает это плод кративненькой работы твоего мозга
Ну, в любом случае, спасибо!
Полезное тоже присутствовало.

[Хакер]

Классная манера вырывать посты из контекста и в данном случае вообще из другого обсуждения. Это я не тебе писал, зачем ты это цитируешь?

Всё таки ты утверждал, что многопоточный вариант, который (ты говоришь) мне тут любезно предложили - это вообще-то не вариант.

Я такого не утверждал. То что для тебя «стабильной многопоточности нет» и «вообще не вариант» тождественно равны — это проблема твоего восприятия. Я в том посте писал, что нет простого как щелчок пальцами способа получить стабильную многопоточность в Standard EXE. Стабильную — это значит что можно без задней мысли писать код, ничего не опасаясь, или запустить в новом потоке код, который вообще писал для другой ситуации другой человек, который заранее не знал, что его код будет работать в многопоточной среде. Вот такой возможности без моего кирпича, а просто так из коробки — нет. Именно это я и имел в виду, и том топике, откуда ты это взял, это было понятно.

Тот факт, что ты это переварил и превратил в «вообще не вариант» — это уже не моя проблема.

Я никаких «вообще не вариант» не говорил. Вполне себе вариант, но придётся идти словно по минному полю. Но для сапёра это норма жизни.

И тут ты тоже утверждал, что API не имеют нормального механизма асинхронных уведомлений, цитировать не буду, ты всё равно придумаешь альтернативную версию моего мнения, того, что я хотел сказать и думал.

Нет, ты это не будешь и не можешь цитировать ровно по той причине, потому что я такого не писал. «Нет нормального механизма» — это обобщённое размазывание соплей по стенам. Я написал проблему асинхронных API весьма конкретизированно: «синхронные API (дико глючный WinInet и более нормальный WinHTTP) не имеют механизма асинхронных уведомлений такого, чтобы дёргался именно поток-заказчик.». Улавливаешь суть? callback будет дёргаться в каком-попало потоке, а не в том, который заказал асинхонную операцию. Это не катастрофа, это значит надо сделать callback, который будет сам отстукиваться в основной поток. Например слать оконное сообщение. Это решается в два счёта, и тут никакой мой кирпич не обязателен.



Таким образом, не надо тут пытаться задним числом выставить всё так, словно ты говорил об однопоточном подходе без асинхронным API.
Ты конкретно сказал: «асинхронность не спасёт от подлагиваний» (что было названо чушью). Ты можешь из кожи вылезти, но ты не отвертишься от того факта, что твоё предложение:

асинхронность не спасает от подтормаживания в момент коннекта или передачи запроса при медленном канале.

относилось именно к использованию асинхронных API, а не к однопоточному Standard EXE без асинхронности.

И вообще, оба твоих предложения были высказаны в ответ на призыв использовать однопоточный Standard EXE + асинхронный режим API. Если ты в ответ на призыв использовать это говоришь о том, что тебе кажется, что будет подлагивать, то только идиот поверит, что ты в тот момент имел в виду вовсе не асинхронные API, а что-то другое. И не надо пытаться выкрутиться, отыскивая какие-то мои посты из других дискуссий.

[Adam Smith]

Разумеется я говорил именно об однопоточном приложении. Смотрика, ты это признал чтоле?
Но в общем всё так, как я и предполагал. Фантазия не имеющая ко мне отношения.
Правда с сапёром ты был на грани, ну ниче, главное, чтобы самому нравилось)

[Adam Smith]

Только идиот мог подумать, что я имел ввиду многопоточность хуже многопроцессности.
Ааа, ну да, это же уже другая дискуссия, зачем на неё ссылаться, тут новая идея развивается.

[Adam Smith]

Переписал работу с API сокетом, получаю в байт-массив, копирую его в "массив" байт-массивов, по ходу считаю общее кол-во байт.
После закрытия сокета создаю новый байт-массив под считанное кол-во байт, собираю в него скачанный "массив" байт-массивов.
Первый байт-массив из "массива" преобразую в строку, получаю размер заголовка ответа и проверяю на наличие chunked.

Это ваша заслуга.