Веб-паук / сканер в C # Windows.forms

Question

Я создал веб-сканер в VC #. Сканер индексирует определенную информацию с сайтов .nl, перебивая все возможные адреса .nl, начиная с http://aa.nl до (теоретически) http://zzzzzzzzzzzzzzzzzzzz.nl.

Это работает нормально, за исключением того, что требуется невероятно много времени, чтобы пройти через двухбуквенные домены - aa, ab ... zz. Я подсчитал, сколько времени мне понадобится, чтобы пройти через все домены таким образом, и я получил около тысячи лет.

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

У меня нет доступа ни к чему другому, кроме подключения к Интернету со скоростью 5 Мбит / с, E6300 Core2duo и 2 ГБ оперативной памяти 533 @ 667 МГц на Win7.

У кого-нибудь есть идеи, что делать, чтобы сделать эту работу? Любая идея подойдет. Спасибо

Answer 1

Комбинаторный взрыв делает это невозможным (если только вы не можете подождать, по крайней мере, несколько месяцев).Вместо этого я бы попытался связаться с SIDN , который является полномочным лицом для домена верхнего уровня .nl, и запросить у них список.

Answer 2

IMO такая реализация веб-сканера не подходит

1. Количество пингов, которые необходимо выполнить для одного сканирования, составляет ~ 10 ²⁹
2. Скажем, каждый пинг занимает 200 мс
3. Время обработки 100 мс

Общая оценка времени 3 * 10 ⁴ * 10 ²⁹ мс ~ 3 * 10 ²³ лет . Пожалуйста, поправьте меня, если я ошибаюсь.

Если вы хотите воспользоваться преимуществами многопоточности, вам нужно иметь выделенное ядро ​​для каждого потока. Каждый поток займет не менее 1 МБ вашей памяти.

Threading вам здесь не поможет, вы сможете гипотетически сократить время до ~ 3 * 10 ²⁰ лет

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

Answer 3

Поддержка HTTP в .Net имеет максимальный предел одновременных подключений около 8 по умолчанию, я думаю (где-то около этой цифры в любом случае)

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