Асинхронная передача GET/POST

Привет! Есть вопрос к знатокам и админам. Скажите, пожалуйста, можно ли в ZP отправить несколько GET/POST запросов одновременно и положить ответы в несколько переменных или список? Интересует реализация на C#.

etyipin сказал(а):

Было на в конкурсной статье http://zennolab.com/discussion/threads/parallelnye-zaprosy.19609/

Нажмите, чтобы раскрыть...

Да, это решение я уже изучил. Спасибо. Но по большей части интересуют POST запросы и в идеале при помощи стандартных методов ZP (чтобы была возможность менять UserAgent и добавлять пользовательские HTTP заголовки).

etyipin сказал(а):

А что мешает заменить GET на POST https://help.zennolab.com/en/v5/zennoposter/5.15.0.0/webframe.html#topic609.html ?

Нажмите, чтобы раскрыть...

Спасибо. Разобрался.

Возникла проблема при работе с асинхронным GET/POST. Опишу её суть на примере. Мне необходимо скачать 100 страниц с целевого сайта в асинхронном режиме. Но при этом это надо сделать так, чтобы необходимая информация с этих страниц сохранилась в список по порядку, т.е. сперва сохранилась информация со страницы 1, потом со страницы 2, потом 3... и т.д. Но при запуске парсинга в асинхронном режиме поток 90 может отработать раньше, чем поток 10. Соответственно данные с со страницы 90 лягут в список выше, чем со страницы 10 и получится каша. Пауза между потоками не решает задачи (проверил на практике), да и использование паузы — это плохое решение, т.к. пауза сводит на «нет» всё преимущество параллельного выполнения. Соответственно нужно нечто асинхронной очереди, чтобы запросы отправились последовательно, но результат обрабатывался одновременно.

P.S.
Или, быть может, есть аналог вот этой опции:



но для кубиков GET/POST запросов? Т.е. чтобы можно было было отправить несколько GET/POST запросов один за другим без ожидания ответа.

doc сказал(а):

по ссылке, что давали выше в цикле есть индекс. ЧТо мешает сохранять последовательность за его счёт?

Нажмите, чтобы раскрыть...

Изначально я так и реализовал, после чего и столкнулся с проблемой. Дело в том, что потоки в рамках данного цикла стартуют одновременно, но код выполняют с разной скоростью (в основном за счет разной скорости ответа удаленного сервера), поэтому к финишу они приходят в разное время даже если каждый индекс умножить на секундную паузу.. Конечно, чем дольше пауза, тем выше вероятность последовательного завершения, но тем дольше и общее время выполнения. Настолько дольше, что весь смысл параллельности теряется.

doc сказал(а):

не надо ничего умножать. Нужно создать массив с количеством элементов равному количеству ссылок и записывать в цикле ответы по индексу

Нажмите, чтобы раскрыть...

Буду благодарен, если покажете на примере того кода, который дан по ссылке выше.

workoles сказал(а):

Буду благодарен, если покажете на примере того кода, который дан по ссылке выше.

Нажмите, чтобы раскрыть...

Хотя в общем-то я смысл понял, предложение имеет место быть, но в данном случае все осложняется тем, что каждый запрос должен содержать параметр в виде порядкового номера обращения к серверу и нельзя допустить, чтобы сперва обращение было сделано к 90 странице, а затем к 10 (если вернуться к примеру), т.е. по факту сами запросы должны быть сделаны последовательно, но без задержки на ожидание ответа.

amyboose сказал(а):

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

Нажмите, чтобы раскрыть...

Понял. Жалко, конечно. Параллельность хорошая штука, но, видимо, не универсальна.

@nuaru Скажите, пожалуйста, есть ли возможность сделать аналогичную опцию:



но не для браузера, а непосредственно для кубиков GET/POST запросов? Т.е. чтобы можно было отправить несколько GET/POST запросов последовательно один за другим без ожидания ответа.