Действительно, Ваше замечание верно. Правда, как я и говорил выше сильно оптимистично, но тем не менее. Вот что у меня получилось.
Если асинхронно посылать запросы и ждать их завершения (синхронизировать для записи в файл) сразу для 256 ip адресов, то на это уходит 23088 ms против 26838 ms при полностью синхронном ожидании. Действительно, таймаут можно увеличить в этом случае до 500ms и это влиять существенно не будет: 23146ms против 122059 ms.
Ну реальная производительность увеличивается если число асинхронных запросов увеличить скажем 256*4, уже дает 31830 ms.
Но тут имеется и верхняя граница. Ни чего делить по кол-ву ядер не нужно, C# при асинхронных вызовах сам все успешно делит на потоки, а система под разные потоки выделяет необходимое число загрузки ядер. Так скажем, у меня 2 процессора по 4 ядра. Если я выполняю все синхронно задействуется примерно 12% общего времени CPU. Теперь я сделал тест на асинхронный скан 256*N ip адресов, при этом процессорное время бегало от 20% до 60%, ну в среднем 50%, скажем так было задействовано 4 ядра.
Результат:
256*4 дает 31830 ms
256*8 дает 45242 ms
256*16 дает 79411 ms
256*32 дает 168464 ms
256*64 недождался
т.е. с ростом асинхронных запросов без синхронизации производительность вначале растет, а потом падает. Выше 256*16 уже идет замедление. Посчитаем выигрыш при 256*16 = 80 сек. * 16 = есть вероятность что получу за 21 минуту вместо 109 упомянутых в статье. Но там однопроцессорное время, приведем 109/4 — 21 = 33 мин. выигрыш, т.е. где-то 160% чистый выигрыш
Проблемы в том, что они размазаны никакой, пусть они балансирую нагрузку. Речь же о публичности/легкой доступности этой информации, а тут вы лукавите. По IP можно было бы получить список всех сайтов, использующих этот IP (я же не говорил, что мне нужно однозначное соответствие). Кстати, бот гугла как то находит эти сайты? Откуда он их узнает если они появились только что?
Ну, и конечно, пока это лишь идея о «поисковиках нового типа» — никто с этим считаться не будет (капитан америка), но если бы тот же гугл по умолчанию не индексировал бы такие «крупные сайты», то думаю от их «крупности» ничего бы не осталось бы. Ну, а так пока что «мифический поисковик» будет работать с сайтами «менее крупными», но с публичной информацией.Их я думаю тоже достаточно :). А хитрицы пусть покурят в сторонке, честно говоря я не понимаю тех кто желает скрыть IP сайта, кроме явно жуликов и закрытой информации. А приватный сектор и жуликов исключить из поисковиков — это лишь на благо. И речь же как раз о том, что доверия к индексированию нет, и то что это индексирование мало что отражает.
Ну это дорога с двустороним движением, скрывать связь ip-домен — это исключить сайт для поиска в поисковиках, скажем так «нового типа» поддерживающих прозрачность веб-владельца. И еще вопрос, чего больше захотят пользователи :)
Я вполне себе отдаю отчет, что сейчас в этом отношении творится полный бардак, который и описал в статье и на каком уровне можно считать, что IP принадлежит стране. Нужно/ненужно — это ваше сугубо личное мнение, основанное на том какую цель Вы приследуете.
На первом этапе, отрезать русскоязычные сайты, находящихся не на российских IP — это не проблема вообще. Найти и и выделить их тоже не проблема — определить по языку используемому на сайте. Не проблема отрезать — потому что, нужно понимать главное — поисковику должны докладывать где и какие страны. В идеале, любой сайт должен сообщать свою страну вплане физического расположения — но это, как я и написал легко выяснить, а так же свой язык — скажем в заголовке HTTP, а сайты же не подчиняющиеся этой хорошой манеры, надо просто исключить из поиска. Далее все зависит от желаний пользователя — хотят они понимать куда они заходят и какой контент ищут — такой поисковик будет пользоваться успехом, нет — воспользуются другим.
Но такого рода поисковика я пока не вижу, и в этом проблема. «ищу я к примеру «mvc framework»» — надо вам и указать Вы хотите объяыснение получить на русском, английсом или китайском? Используя вышеописанное вам и найдут соответствующие из проверенного контента без мусора. (добавить мусор, не проблема, сложнее его убрать)
На самом деле, я и использую неблокируемые (асинхронные) сокеты, жду от них ответа 100ms. Действительно, можно сделать по другому, о чем я уже написал выше (и что по сути и используется в masscan/nmap). Но мне не хотелось, делать это асинхронно (хотя может это и окажется выгодно). Но думаю вы преувеличиваете возможности такой параллельности. Действительно, есть проблема «провайдер не заблокировал канал, посчитав ваш трафик SYN Flood атакой». Но и кроме того, что надо послать запрос и получить ответ, надо еще записать ответ в файл (делать это асинхронно, не удобно). Придется все равно синхронизировать ответы в какой-то структуре в оперативной памяти и выгружать на диск переодически. На первый взгляд, мне не показалось это быстрее, но можно попробовать, если это ускорит раз в 10 тоже уже хорошо.
действительно, можно попробовать не ждать ответа с каждого IP как я делаю, но не думаю, что это действительно так быстро, хотя может и ускорить положение дел. На днях попробую. Спасибо за идею.
* Пингом я назвал это условно, там C# функция tcpClient.BeginConnect(ipAddress, Port, null, null);
* сетей провайдеров домашнего интернета — там вполне могут быть веб-сайты
* 1 ip != 1 сайт — а я и не говорил такого, но проверить каждый IP — чтобы понять где есть сайты, и наоборот как сайты используют IP достаточно важно. Про актуальность неясно — вопрос лишь в частоте проверки.
Может вначале стоит почитать ну к примеру Канта, поупражняться в доказательстве, что мир конечен, а потом доказать, что бесконечен… понять что многие ИТ-специалисты в этом упражняются по долгу службы, и потом написать подобную статью, но уже имея больший «кругозор»?
Итого, сайт почти верно говорит если разделить на 2…
Т.е. 35к = это что-то около 700 EUR? Ну скажем я сейчас под Ригой плачу 100 EUR в своей квартире, если взять в кредит то было бы 300 EUR, если снимать в Риге ну макс 400… еда и того меньше 50-80 EUR на неделю на семью, если ходить в кафе то 10 -15 EUR на троих плотно поесть и выпить пива
Мне одному показалось, что тут один философ с очень большим эмпирическим исследованием ооочень объективно сделал вывод о узости мышления ИТ-специалистов, и посоветовал размазать свое мнение по бутерброду информационного мусора?
И где же тут ошибка? Я разве где-то написал другое? Я именно про разное поведение this и написал, а lair переписал это только своими словами и ничего более :)
Полностью Вас поддерживаю, в последнию неделю и моей кармы коснулась такая участь, вот подумываю наверно уйти с хабра, хотя иногда приличные люди тут встречаются :)
Ну, и кто это здесь заносчив :) заканчивайте говорить в стиле Ad hominem — это Вас не красит.
" трёхдневное знакомство с TS как глубокое понимание предмета"
Однако, мне этого было достаточно, чтобы перевести мое проектик. Все остальное придумыли Вы сами, я же поделился теми трудностями с которыми столкнулся. Ну, и в скобках заметим, Вы читаете мою статью — с удовольствиям почитал бы статьи здешних умников, однако таких статей нет.
«судя по ошибкам в статье, вы также мало знакомы с C#»
смешно :) Может стоит вначале назвать в чем ошибка, а потом уже что-то утверждать?
P.S.
Приезжайте к нам, может и я устрою вас на работу :)
Да, нет там ничего по делу :) Объяснять очевидности мне тут не интересно. Но если вам реально интересно, пишите в личку — попробуем разобраться. А так это очередной холивар, мне он не интересен.
Если асинхронно посылать запросы и ждать их завершения (синхронизировать для записи в файл) сразу для 256 ip адресов, то на это уходит 23088 ms против 26838 ms при полностью синхронном ожидании. Действительно, таймаут можно увеличить в этом случае до 500ms и это влиять существенно не будет: 23146ms против 122059 ms.
Ну реальная производительность увеличивается если число асинхронных запросов увеличить скажем 256*4, уже дает 31830 ms.
Но тут имеется и верхняя граница. Ни чего делить по кол-ву ядер не нужно, C# при асинхронных вызовах сам все успешно делит на потоки, а система под разные потоки выделяет необходимое число загрузки ядер. Так скажем, у меня 2 процессора по 4 ядра. Если я выполняю все синхронно задействуется примерно 12% общего времени CPU. Теперь я сделал тест на асинхронный скан 256*N ip адресов, при этом процессорное время бегало от 20% до 60%, ну в среднем 50%, скажем так было задействовано 4 ядра.
Результат:
256*4 дает 31830 ms
256*8 дает 45242 ms
256*16 дает 79411 ms
256*32 дает 168464 ms
256*64 недождался
т.е. с ростом асинхронных запросов без синхронизации производительность вначале растет, а потом падает. Выше 256*16 уже идет замедление. Посчитаем выигрыш при 256*16 = 80 сек. * 16 = есть вероятность что получу за 21 минуту вместо 109 упомянутых в статье. Но там однопроцессорное время, приведем 109/4 — 21 = 33 мин. выигрыш, т.е. где-то 160% чистый выигрыш
Ну, и конечно, пока это лишь идея о «поисковиках нового типа» — никто с этим считаться не будет (капитан америка), но если бы тот же гугл по умолчанию не индексировал бы такие «крупные сайты», то думаю от их «крупности» ничего бы не осталось бы. Ну, а так пока что «мифический поисковик» будет работать с сайтами «менее крупными», но с публичной информацией.Их я думаю тоже достаточно :). А хитрицы пусть покурят в сторонке, честно говоря я не понимаю тех кто желает скрыть IP сайта, кроме явно жуликов и закрытой информации. А приватный сектор и жуликов исключить из поисковиков — это лишь на благо. И речь же как раз о том, что доверия к индексированию нет, и то что это индексирование мало что отражает.
На первом этапе, отрезать русскоязычные сайты, находящихся не на российских IP — это не проблема вообще. Найти и и выделить их тоже не проблема — определить по языку используемому на сайте. Не проблема отрезать — потому что, нужно понимать главное — поисковику должны докладывать где и какие страны. В идеале, любой сайт должен сообщать свою страну вплане физического расположения — но это, как я и написал легко выяснить, а так же свой язык — скажем в заголовке HTTP, а сайты же не подчиняющиеся этой хорошой манеры, надо просто исключить из поиска. Далее все зависит от желаний пользователя — хотят они понимать куда они заходят и какой контент ищут — такой поисковик будет пользоваться успехом, нет — воспользуются другим.
Но такого рода поисковика я пока не вижу, и в этом проблема. «ищу я к примеру «mvc framework»» — надо вам и указать Вы хотите объяыснение получить на русском, английсом или китайском? Используя вышеописанное вам и найдут соответствующие из проверенного контента без мусора. (добавить мусор, не проблема, сложнее его убрать)
* сетей провайдеров домашнего интернета — там вполне могут быть веб-сайты
* 1 ip != 1 сайт — а я и не говорил такого, но проверить каждый IP — чтобы понять где есть сайты, и наоборот как сайты используют IP достаточно важно. Про актуальность неясно — вопрос лишь в частоте проверки.
Т.е. 35к = это что-то около 700 EUR? Ну скажем я сейчас под Ригой плачу 100 EUR в своей квартире, если взять в кредит то было бы 300 EUR, если снимать в Риге ну макс 400… еда и того меньше 50-80 EUR на неделю на семью, если ходить в кафе то 10 -15 EUR на троих плотно поесть и выпить пива
Так а какого фига тогда в Москве делать :)
" трёхдневное знакомство с TS как глубокое понимание предмета"
Однако, мне этого было достаточно, чтобы перевести мое проектик. Все остальное придумыли Вы сами, я же поделился теми трудностями с которыми столкнулся. Ну, и в скобках заметим, Вы читаете мою статью — с удовольствиям почитал бы статьи здешних умников, однако таких статей нет.
«судя по ошибкам в статье, вы также мало знакомы с C#»
смешно :) Может стоит вначале назвать в чем ошибка, а потом уже что-то утверждать?
P.S.
Приезжайте к нам, может и я устрою вас на работу :)