[Rio-pm] AnyEvent

Junior Moraes juniiior182 em gmail.com
Quinta Março 15 07:49:07 PDT 2012


Hi.

Deixa eu adentrar ao assunto...
Como assim depois de ICMP flood? Não era UDP? LOL

Não perca tempo com ICMP flood. Sério.

[]'s

Em 15 de março de 2012 11:42, Aureliano Guedes
<guedes_1000 em hotmail.com>escreveu:

>  Realmente, depois de ICMP flood vou fazer syn flood.
>
> > From: tiago.peczenyj em gmail.com
> > Date: Thu, 15 Mar 2012 11:21:19 -0300
>
> > To: rio-pm em pm.org
> > Subject: Re: [Rio-pm] AnyEvent
> >
> > Acho que simplifiquei.
> >
> > Vc pode ter cpu e memoria "tranquilos" e o gargalo ficar na camada de
> > transporte se a sua aplicação for leve o suficiente para vc violentar
> > as placas de rede. Não é um problema, é apenas conhecer o
> > limite/gargalo/etc. Ai vc troca a placa ou adiciona mais uma e testa
> > novamente ate que outro problema surja.
> >
> > Ai vc pode descobrir que quem programou as rotinas multithread para
> > suportar multiplas conexões simultâneas aprendeu a programar em C++ em
> > 21 dias com um livro safado e escolhe se vai xingar muito no twitter
> > ou usar outra coisa.
> >
> > Ah, falei syn flood pois me lembrei disso na hora :)
> >
> > On Thu, Mar 15, 2012 at 11:15 AM, Stanislaw Pusep <creaktive em gmail.com>
> wrote:
> > > Thiago: sim, na camada da aplicação, CPU quase certamente será o
> gargalo
> > > (vide C10k problem). Mas na camada de transporte?!
> > > Aureliano: Win95 *sem Service Pack* "morre" pelo WinNuke, que consiste
> de um
> > > pacote TCP com flag Out-Of-Band para a porta 139 :)
> > > Aliás, SYN flood é BEM diferente de ICMP flood; é exploit de
> protocolo, não
> > > por "força bruta".
> > >
> > > ABS()
> > >
> > >
> > >
> > >
> > > On Thu, Mar 15, 2012 at 11:08, Tiago Peczenyj <
> tiago.peczenyj em gmail.com>
> > > wrote:
> > >>
> > >> Depende da aplicação ou infra-estrutura.
> > >>
> > >> Uma versão antiga do servidor de streaming de video da adobe tinha CPU
> > >> como gargalo, não chegava a usar 70% das placadas de rede disponiveis,
> > >> isso foi corrigido nas mais recentes. Mas isso é facilmente explicado:
> > >> primeiro foi desenvolvida a versão para windows, depois foi portado
> > >> para linux (que foi objeto de testes).
> > >>
> > >> Hoje com 2 placas 10 gigabits o cenário mudou de novo: existe alguma
> > >> limitação interna que num dado numero x de pessoas conectadas o
> > >> sistema começa a degenerar qualidade e rejeita clientes novos. Ainda
> > >> estamos investigando porém isso não é critico (por incrivel que
> > >> pareça). Uma suspeita é a forma como os processos se comunicam entre
> > >> si, mas como é um produto fechado só resta sentar e esperar.
> > >>
> > >> On Thu, Mar 15, 2012 at 11:00 AM, Stanislaw Pusep <
> creaktive em gmail.com>
> > >> wrote:
> > >> >> Realmente acho que a rede dificilmente seria o gargalo, logo vou me
> > >> >> concentrar na memoria e no CPU.
> > >> >
> > >> >
> > >> > Neste ponto, você está MUITO errado.
> > >> >
> > >> > _______________________________________________
> > >> > Rio-pm mailing list
> > >> > Rio-pm em pm.org
> > >> > http://mail.pm.org/mailman/listinfo/rio-pm
> > >>
> > >>
> > >>
> > >> --
> > >> Tiago B. Peczenyj
> > >> Linux User #405772
> > >>
> > >> http://pacman.blog.br
> > >> _______________________________________________
> > >> 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
> >
> >
> >
> > --
> > Tiago B. Peczenyj
> > Linux User #405772
> >
> > http://pacman.blog.br
> > _______________________________________________
> > 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>
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://mail.pm.org/pipermail/rio-pm/attachments/20120315/b986633b/attachment-0001.html>


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