[Rio-pm] Multi threads

cicero.schons cicero.schons em gmail.com
Segunda Março 12 07:42:56 PDT 2012


Olá,
Se o foco seria a segurança, acho que seria mais produtivo modificar os
pacotes ICMP, spoofar os ips e mac de origem para aumentar a carga no
destino. Outra sugestão é: se o destino for um modem simples ou algo do
tipo, tente MAC Flood...

Abraço.

Em 12 de março de 2012 09: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
>
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://mail.pm.org/pipermail/rio-pm/attachments/20120312/0e2e70c6/attachment-0001.html>


Mais detalhes sobre a lista de discussão Rio-pm