[Rio-pm] Multi threads

Segunda Março 12 06:14:10 PDT 2012

Too mainstream: http://en.wikipedia.org/wiki/Syn_cookie

ABS()

On Mon, Mar 12, 2012 at 10:08, Junior Moraes <juniiior182 em gmail.com> wrote:

> Hi.
>
> Acpguedes, você definitivamente não vai conseguir muita coisa fazendo ICMP
> flood por mais performático que o seu script seja.
> E, ainda neste caso, o gargalo não seria processamento.
>
> Se quiser estudar técnicas de Denial of Service, faz uma brincadeira com
> SYN flood e aí a coisa começa a ficar séria. :-)
>
> []'s
>
> Em 12 de março de 2012 10:04, Vinícius Miasato <viniciusmiasato em gmail.com>escreveu:
>
> Olá Aureliano,
>>
>> deixa ver se entendi bem, você pretende utilizar a GPU para atacar a rede
>> ?
>>
>> abs.
>> Japa
>>
>> 2012/3/12 Aureliano Guedes <guedes_1000 em hotmail.com>:
>> > Hoje em dia os moldens mais simples pode bloquear ping por defaut,
>> contudo
>> > no trecho citado vc falou de 2GHz.
>> >
>> > Testa um i7 e usando GPU com uma placa de video poderosa, levando uma
>> > internet de 15MB/s (a minha é so 10MB/p).
>> >
>> > Facilitaria bastante, não?
>> >
>> > No meu caso, como sou programador por esporte, e me interesso pela
>> parte de
>> > segurança digital, quero aprender intimamente
>> > a parte "underground", para isso tenho uma rede configurada onde um
>> Windows
>> > 95 esta me esperando pra brincar com ele.
>> > ________________________________
>> > From: creaktive em gmail.com
>> > Date: Mon, 12 Mar 2012 09:42:52 -0300
>> >
>> > To: rio-pm em pm.org
>> > Subject: Re: [Rio-pm] Multi threads
>> >
>> > Da documentação do AnyEvent::FastPing:
>> >
>> > "Performance: On my 2 GHz Opteron system with a pretty average nvidia
>> > gigabit network card I can ping around 60k to 200k addresses per second,
>> > depending on routing decisions"
>> >
>> > Tentar isso com threads certamente vai derrubar o host... O SEU :P
>> >
>> > ABS()
>> >
>> >
>> >
>> > On Mon, Mar 12, 2012 at 09:01, Vinícius Miasato <
>> viniciusmiasato em gmail.com>
>> > wrote:
>> >
>> >>Ainda dá pra derrubar servidor com ping hoje
>> >> em dia?
>> >
>> > dependendo do servidor, sim, mas creio que são raridades hoje em dia,
>> >
>> >>Tem uma coisa que a maioria ignora sobre threads, que é o fato de elas
>> >>serem utilizadas para rodar código em paralelo quando o processador
>> >>está *ocioso*.
>> >
>> > não necessariamente. não se usa threads para rodar código somente pelo
>> > processador estar ocioso. threads geralmente são utilizadas para
>> > executar tarefas distintas pois quando uma thread entrar em um estado
>> > bloqueante, as demais ainda podem entrar em execução, porém isso
>> > também não é regra.
>> >
>> >> Fique esperto também com a afinidade. Não necessariamente quatro
>> >> threads rodando em um processador com quatro núcleos vão rodar cada
>> >> uma em um núcleo. Eventualmente, você pode criar N threads que rodem
>> >> em apenas um dos núcleos, e aí você se lascou.
>> >
>> > com uma boa programação e se o SO permitir, você pode escolher em qual
>> > núcleo cada processo executa =D
>> >
>> > abs.
>> > Japa
>> >
>> > Em 12 de março de 2012 00:38, Blabos de Blebe <blabos em gmail.com>
>> escreveu:
>> >>> Bem, agora exclareceu mais o assunto na minha cabeça, contudo me
>> deixou
>> >>> com
>> >>> mais medo de usar threads... hahaha.
>> >>
>> >> Se você tem medo de usar threads, então você não está pronto pra usar
>> >> threads.
>> >>
>> >>> Bem, esquecendo o assunto de redes, o que eu pretendo fazer é pingar
>> um
>> >>> servidor, contudo inves de usar 4 bot para
>> >>> enviar 4 pings simultaneos eu quero usar uma unica maquina para enviar
>> >>> esses
>> >>> 4 pings. Mas é so uma questão de estudo
>> >>> nada de underground.
>> >>
>> >> Estudo, sei...
>> >>
>> >> Bem, uma rede bem configurada vai solenemente cagar pro seus pings,
>> >> então vou supor que você está estudando como configurar redes de forma
>> >> a evitar um DoD por ping. Ainda dá pra derrubar servidor com ping hoje
>> >> em dia?
>> >>
>> >>> Exemplos que achei na internet não davam muita mobilidade de escolher
>> o
>> >>> numero de threads e tals.
>> >>
>> >> Exemplos de threads que você (você, um sujeito genérico, ok)
>> >> normalmente são porcaria. O que você precisa é ler com atenção o livro
>> >> de SO do tio Tanenbaum http://www.pearsonhighered.com/tanenbaum.
>> >>
>> >> ...
>> >>
>> >> Tem uma coisa que a maioria ignora sobre threads, que é o fato de elas
>> >> serem utilizadas para rodar código em paralelo quando o processador
>> >> está *ocioso*.
>> >>
>> >> Lembre-se sempre que há um custo para o SO fazer a troca de contexto e
>> >> se o seu código for CPU bound, fazer o processador ficar chaveando
>> >> contexto quando ele deveria estar processando, é perda de tempo.
>> >>
>> >> Threads são melhores utilizadas para executar tarefas enquanto alguma
>> >> parte do código está esperando I/O. Por exemplo, interface gráfica,
>> >> que fica fica esperando o usuário interagir, ou ainda código que faz
>> >> I/O, como o seu caso.
>> >>
>> >> Fique esperto também com a afinidade. Não necessariamente quatro
>> >> threads rodando em um processador com quatro núcleos vão rodar cada
>> >> uma em um núcleo. Eventualmente, você pode criar N threads que rodem
>> >> em apenas um dos núcleos, e aí você se lascou.
>> >>
>> >>
>> >> []'s
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> 2012/3/11 Aureliano Guedes <guedes_1000 em hotmail.com>:
>> >>> Bem, agora exclareceu mais o assunto na minha cabeça, contudo me
>> deixou
>> >>> com
>> >>> mais medo de usar threads... hahaha.
>> >>>
>> >>> Bem, esquecendo o assunto de redes, o que eu pretendo fazer é pingar
>> um
>> >>> servidor, contudo inves de usar 4 bot para
>> >>> enviar 4 pings simultaneos eu quero usar uma unica maquina para enviar
>> >>> esses
>> >>> 4 pings. Mas é so uma questão de estudo
>> >>> nada de underground.
>> >>>
>> >>> Exemplos que achei na internet não davam muita mobilidade de escolher
>> o
>> >>> numero de threads e tals.
>> >>>
>> >>> Mas valeu, monges, me ajudou muito mesmo.
>> >>>
>> >>>> Date: Sun, 11 Mar 2012 22:58:20 -0300
>> >>>> From: viniciusmiasato em gmail.com
>> >>>
>> >>>> To: rio-pm em pm.org
>> >>>> Subject: Re: [Rio-pm] Multi threads
>> >>>>
>> >>>> só para não ficar confuso demais, a variável $pool_thr[ $i ] não
>> >>>> recebe o retorno das threads. ela serve como uma forma de controle
>> das
>> >>>> threads, para efetuar join, detach ou executar outros métodos
>> >>>> fornecidos,
>> >>>>
>> >>>> o link para a documentação mais detalhada estpa abaixo:
>> >>>> http://perldoc.perl.org/threads.html
>> >>>>
>> >>>> abs.
>> >>>> Japa
>> >>>>
>> >>>> Em 11 de março de 2012 22:53, Vinícius Miasato
>> >>>> <viniciusmiasato em gmail.com> escreveu:
>> >>>> > olá Aureliano,
>> >>>> >
>> >>>> > parece que você está confundindo um pouco o conceito de threads.
>> >>>> > quando uma thread é criada ela executa em paralelo ( assumindo que
>> sua
>> >>>> > máquina possui vários nucleos e seu SO dá suporte à multi-threads
>> ).
>> >>>> >
>> >>>> > o código que você citou espera a rotina terminar antes de iniciar
>> uma
>> >>>> > nova iteração do loop, já com threads, o loop continua mesmo sem a
>> >>>> > thread retornar, caso a tarefa seja grande o suficiente,
>> >>>> >
>> >>>> > o que o Buss falou está certo, então venho tentar adicionar algo à
>> >>>> > mais,
>> >>>> >
>> >>>> > como você não menciona nada sobre controle de threads, talvez você
>> não
>> >>>> > precise manter o controle das threads ao cria-las, então você pode
>> >>>> > efetuar um detach nelas, o que significa descartar qualquer
>> retorno da
>> >>>> > thread em questão. após um detach, a thread não poderá mais ser
>> >>>> > controlada.
>> >>>> >
>> >>>> > caso queira esperar um thread específica retornar antes de criar as
>> >>>> > outras você  pode efetuar um join para aguardar o término da mesma,
>> >>>> >
>> >>>> > seria algo como:
>> >>>> >
>> >>>> > my $thr =  threads->create(\&sub1);
>> >>>> > $thr->detach; # não queremos saber sobre o retorno desta thread e
>> >>>> > liberamos ela
>> >>>> >
>> >>>> > ou
>> >>>> >
>> >>>> > my $thr2 =  threads->create(\&sub2);
>> >>>> > my $resposta = $thr->join; # o retorno da sub2 atribuído à variável
>> >>>> > escalar $resposta
>> >>>> >
>> >>>> > para o caso de você querer receber o resultado de cada thread
>> criada,
>> >>>> > vale à ideía do Buss de criar um array no loop aonde as threads são
>> >>>> > criadas,
>> >>>> > ficando mais ou menos assim:
>> >>>> >
>> >>>> > my @pool_thr;
>> >>>> > for (my $i =1; $i = 5; $i++){
>> >>>> >    $pool_thr[ $i ] = threads->create(\&sub1);
>> >>>> > }
>> >>>> >
>> >>>> > sub sub1 {
>> >>>> > ....
>> >>>> > }
>> >>>> >
>> >>>> > quanto ao exemplo do servidor, mesmo com threads ou forks, enfim
>> >>>> > vários processos em paralelo, você ainda terá outro provável
>> gargalo,
>> >>>> > que é a parte de rede,
>> >>>> >
>> >>>> > abs.
>> >>>> > Japa
>> >>>> >
>> >>>> > 2012/3/11 Aureliano Guedes <guedes_1000 em hotmail.com>:
>> >>>> >> Na verdade, eu acho que minha pergunta que foi feita de forma
>> errada.
>> >>>> >> Eu queria, por exemplo, dar ping em um servidor ate derruba-lo,
>> >>>> >> contudo
>> >>>> >> eu
>> >>>> >> queria para isso enviar digamos, 5 pacotes simultaneos,
>> >>>> >> inves de enviar 1 por vez.
>> >>>> >>
>> >>>> >> Mas eu entendi quanto a usar o laço, talvez eu realmente faça
>> isso.
>> >>>> >> Contudo,
>> >>>> >> usar
>> >>>> >>
>> >>>> >> for (my $i =1; $i <= 5; $i++){
>> >>>> >> my $thr = threads->create(\&sub1);
>> >>>> >> }
>> >>>> >>
>> >>>> >> não é o mesmo que usar apenas
>> >>>> >>
>> >>>> >>
>> >>>> >> for (my $i =1; $i <= 5; $i++){
>> >>>> >> &sub1;
>> >>>> >> }
>> >>>> >>
>> >>>> >> se a função do meu sub1 for apenas enviar pacotes a um servidor???
>> >>>> >>
>> >>>> >> ________________________________
>> >>>> >> From: bruno.buss em gmail.com
>> >>>> >> Date: Sun, 11 Mar 2012 22:29:06 -0300
>> >>>> >>
>> >>>> >> To: rio-pm em pm.org
>> >>>> >> Subject: Re: [Rio-pm] Multi threads
>> >>>> >>
>> >>>> >> 2012/3/11 Aureliano Guedes <guedes_1000 em hotmail.com>
>> >>>> >>
>> >>>> >> Opa, Bruno, valeu a resposta, mas vamos ver se eu entendi
>> >>>> >>
>> >>>> >>  eu poderia fazer assim:
>> >>>> >>
>> >>>> >>     use threads;
>> >>>> >>
>> >>>> >>
>> >>>> >>     for (my $i =1; $i = 5; $i++){
>> >>>> >>     my $thr = threads->create(\&sub1);
>> >>>> >>
>> >>>> >>
>> >>>> >>     sub sub1 {
>> >>>> >>
>> >>>> >>     }
>> >>>> >> }
>> >>>> >>
>> >>>> >> Mas assim não ocorreria  execução simultanea, certo? Pois cada
>> >>>> >> execução
>> >>>> >> iria
>> >>>> >> ocorrer uma por vez a cada contagem do contador.
>> >>>> >>
>> >>>> >>
>> >>>> >> A resposta para sua pergunta: errado.
>> >>>> >> Porém sua explicação está "correta"... a cada iteração do for,
>> será
>> >>>> >> criada
>> >>>> >> uma nova thread, então você terá disparado diversas threads até o
>> >>>> >> final
>> >>>> >> do
>> >>>> >> for.
>> >>>> >>
>> >>>> >> Agora, o ponto em ser simultâneo é um pouco mais complicado:
>> depende
>> >>>> >> de
>> >>>> >> quantos cores tem seu sistema (se tiver menos cores que threads
>> >>>> >> utilizadas,
>> >>>> >> então as threads estarão executando de forma concorrente e não
>> >>>> >> simultânea),
>> >>>> >> depende do escalonador de tarefas do seu sistema operacional,
>> dependo
>> >>>> >> do que
>> >>>> >> a sua sub1 faz, etc.
>> >>>> >>
>> >>>> >> Mas acho que a sua dúvida é um pouco mais básica do que isso...
>> >>>> >>
>> >>>> >> Fazer:
>> >>>> >> for (my $i =1; $i <= 5; $i++){
>> >>>> >> [alguma coisa]
>> >>>> >> }
>> >>>> >>
>> >>>> >> é essencialmente igual a fazer [alguma coisa] 5 vezes (tirando o
>> fato
>> >>>> >> que
>> >>>> >> você pode utilizar o parâmetro do for para fazer alterações):
>> >>>> >> [alguma coisa]
>> >>>> >> [alguma coisa]
>> >>>> >> [alguma coisa]
>> >>>> >> [alguma coisa]
>> >>>> >> [alguma coisa]
>> >>>> >>
>> >>>> >> No seu caso,
>> >>>> >> for (my $i =1; $i <= 5; $i++){
>> >>>> >> my $thr = threads->create(\&sub1);
>> >>>> >> }
>> >>>> >>
>> >>>> >> É igual a fazer:
>> >>>> >> my $thr = threads->create(\&sub1);
>> >>>> >> my $thr = threads->create(\&sub1);
>> >>>> >> my $thr = threads->create(\&sub1);
>> >>>> >> my $thr = threads->create(\&sub1);
>> >>>> >> my $thr = threads->create(\&sub1);
>> >>>> >>
>> >>>> >> Que é exatamente o que você queria, não? ;-)
>> >>>> >>
>> >>>> >> [ ]'s
>> >>>> >> --
>> >>>> >> Bruno C. Buss
>> >>>> >> http://brunobuss.wordpress.com/
>> >>>> >> http://www.dcc.ufrj.br/~brunobuss/
>> >>>> >>
>> >>>> >> _______________________________________________ Rio-pm mailing
>> list
>> >>>> >> Rio-pm em pm.org http://mail.pm.org/mailman/listinfo/rio-pm
>> >>>> >>
>> >>>> >> _______________________________________________
>> >>>> >> Rio-pm mailing list
>> >>>> >> Rio-pm em pm.org
>> >>>> >> http://mail.pm.org/mailman/listinfo/rio-pm
>> >>>> _______________________________________________
>> >>>> Rio-pm mailing list
>> >>>> Rio-pm em pm.org
>> >>>> http://mail.pm.org/mailman/listinfo/rio-pm
>> >>>
>> >>> _______________________________________________
>> >>> Rio-pm mailing list
>> >>> Rio-pm em pm.org
>> >>> http://mail.pm.org/mailman/listinfo/rio-pm
>> >> _______________________________________________
>> >> Rio-pm mailing list
>> >> Rio-pm em pm.org
>> >> http://mail.pm.org/mailman/listinfo/rio-pm
>> > _______________________________________________
>> > Rio-pm mailing list
>> > Rio-pm em pm.org
>> > http://mail.pm.org/mailman/listinfo/rio-pm
>> >
>> >
>> >
>> > _______________________________________________ Rio-pm mailing list
>> > Rio-pm em pm.org http://mail.pm.org/mailman/listinfo/rio-pm
>> >
>> > _______________________________________________
>> > Rio-pm mailing list
>> > Rio-pm em pm.org
>> > http://mail.pm.org/mailman/listinfo/rio-pm
>> _______________________________________________
>> Rio-pm mailing list
>> Rio-pm em pm.org
>> http://mail.pm.org/mailman/listinfo/rio-pm
>>
>
>
>
> --
> Junior Moraes (fvox)
> Perl Developer
> http://www.unsecurity.com.br/
>
> <http://www.twitter.com/juniiormoraes> <http://pt-br.facebook.com/juniiormoraes>
>   <http://plus.google.com/104958988925423385684> <http://www.lastfm.com.br/user/juniior182>
>   <http://www.delicious.com/fvox>  <http://github.com/fvox>
>
>
> _______________________________________________
> Rio-pm mailing list
> Rio-pm em pm.org
> http://mail.pm.org/mailman/listinfo/rio-pm
>
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://mail.pm.org/pipermail/rio-pm/attachments/20120312/be937d12/attachment-0001.html>