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

  • Автор темы Автор темы workoles
  • Дата начала Дата начала
workoles

workoles

Client
Регистрация
02.05.2015
Сообщения
276
Реакции
82
Баллы
28
Привет! Есть вопрос к знатокам и админам. Скажите, пожалуйста, можно ли в ZP отправить несколько GET/POST запросов одновременно и положить ответы в несколько переменных или список? Интересует реализация на C#.
 
etyipin написал(а):
Было на в конкурсной статье http://zennolab.com/discussion/threads/parallelnye-zaprosy.19609/
Нажмите для раскрытия...
Да, это решение я уже изучил. Спасибо. Но по большей части интересуют POST запросы и в идеале при помощи стандартных методов ZP (чтобы была возможность менять UserAgent и добавлять пользовательские HTTP заголовки).
 
Возникла проблема при работе с асинхронным GET/POST. Опишу её суть на примере. Мне необходимо скачать 100 страниц с целевого сайта в асинхронном режиме. Но при этом это надо сделать так, чтобы необходимая информация с этих страниц сохранилась в список по порядку, т.е. сперва сохранилась информация со страницы 1, потом со страницы 2, потом 3... и т.д. Но при запуске парсинга в асинхронном режиме поток 90 может отработать раньше, чем поток 10. Соответственно данные с со страницы 90 лягут в список выше, чем со страницы 10 и получится каша. Пауза между потоками не решает задачи (проверил на практике), да и использование паузы — это плохое решение, т.к. пауза сводит на «нет» всё преимущество параллельного выполнения. Соответственно нужно нечто асинхронной очереди, чтобы запросы отправились последовательно, но результат обрабатывался одновременно.

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

vAWaaRc1Wz4zmW.png


но для кубиков GET/POST запросов? Т.е. чтобы можно было было отправить несколько GET/POST запросов один за другим без ожидания ответа.
 
Последнее редактирование:
doc написал(а):
по ссылке, что давали выше в цикле есть индекс. ЧТо мешает сохранять последовательность за его счёт?
Нажмите для раскрытия...
Изначально я так и реализовал, после чего и столкнулся с проблемой. Дело в том, что потоки в рамках данного цикла стартуют одновременно, но код выполняют с разной скоростью (в основном за счет разной скорости ответа удаленного сервера), поэтому к финишу они приходят в разное время даже если каждый индекс умножить на секундную паузу.. Конечно, чем дольше пауза, тем выше вероятность последовательного завершения, но тем дольше и общее время выполнения. Настолько дольше, что весь смысл параллельности теряется.
 
не надо ничего умножать. Нужно создать массив с количеством элементов равному количеству ссылок и записывать в цикле ответы по индексу
 
doc написал(а):
не надо ничего умножать. Нужно создать массив с количеством элементов равному количеству ссылок и записывать в цикле ответы по индексу
Нажмите для раскрытия...
Буду благодарен, если покажете на примере того кода, который дан по ссылке выше.
 
workoles написал(а):
Буду благодарен, если покажете на примере того кода, который дан по ссылке выше.
Нажмите для раскрытия...
Хотя в общем-то я смысл понял, предложение имеет место быть, но в данном случае все осложняется тем, что каждый запрос должен содержать параметр в виде порядкового номера обращения к серверу и нельзя допустить, чтобы сперва обращение было сделано к 90 странице, а затем к 10 (если вернуться к примеру), т.е. по факту сами запросы должны быть сделаны последовательно, но без задержки на ожидание ответа.
 
workoles написал(а):
Хотя в общем-то я смысл понял, предложение имеет место быть, но в данном случае все осложняется тем, что каждый запрос должен содержать параметр в виде порядкового номера обращения к серверу и нельзя допустить, чтобы сперва обращение было сделано к 90 странице, а затем к 10 (если вернуться к примеру), т.е. по факту сами запросы должны быть сделаны последовательно, но без задержки на ожидание ответа.
Нажмите для раскрытия...
Такое сделать нереально в многопоточном режиме. Ты никогда не можешь сказать какой из списка потоков будет выбран процессором следующим. Но можно примерно одновременно начать отправлять запросы
 
  • Оценить
Реакции: workoles
workoles написал(а):
Хотя в общем-то я смысл понял, предложение имеет место быть, но в данном случае все осложняется тем, что каждый запрос должен содержать параметр в виде порядкового номера обращения к серверу и нельзя допустить, чтобы сперва обращение было сделано к 90 странице, а затем к 10 (если вернуться к примеру), т.е. по факту сами запросы должны быть сделаны последовательно, но без задержки на ожидание ответа.
Нажмите для раскрытия...
это в рекламный раздел)
 
amyboose написал(а):
Такое сделать нереально в многопоточном режиме. Ты никогда не можешь сказать какой из списка потоков будет выбран процессором следующим. Но можно примерно одновременно начать отправлять запросы
Нажмите для раскрытия...
Понял. Жалко, конечно. Параллельность хорошая штука, но, видимо, не универсальна.
 
@nuaru Скажите, пожалуйста, есть ли возможность сделать аналогичную опцию:

vAWaaRc1Wz4zmW.png


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

Кто просматривает тему: (Всего: 0, Пользователи: 0, Гости: 0)

Сверху Снизу