[Rio-pm] AnyEvent

Quinta Março 15 08:02:08 PDT 2012

Como ja foi dito: "The actual packet speed of UDP is the same as TCP."

Logo Seria mais conveniente usar Protocolo UDP ou TCP??

Depois, neste codigo -> http://pastebin.com/ewHrXfs8

Esta tudo errado e devo começar do 0 ou ou tem salvação??

Interessante é que quanto mais me aprofundo no assunto mais vejo que nada sei e mais duvidas aparecem... hehehe

From: juniiior182 em gmail.com
Date: Thu, 15 Mar 2012 11:49:07 -0300
To: rio-pm em pm.org
Subject: Re: [Rio-pm] AnyEvent

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/

_______________________________________________
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/20120315/e9f787f9/attachment.html>