[SP-pm] IPC / Data::Dumper

Renato Santos renato.cron at gmail.com
Wed Jul 27 11:56:14 PDT 2011


Esse negocio de IPC nem faz muito sentido,
e a parte de 'outro processo' rodar no CRON faz menos ainda..

E se vc estiver querendo paralelizar requests da uma olhada se você não
acabar fazendo um *DDOS* e tomando BAN do seu fornecedor

2011/7/27 Blabos de Blebe <blabos at gmail.com>

> > Para cada transação vai abrir uma sessão? Não necessariamente. O HTTP é
> > atômico, e para otimizá-lo existe o reaproveitamento de sessão na camada
> de
> > aplicação para ser reaproveitado em diferentes transações.
>
> Cara, HTTP não é necessariamente atômico (depende do que você está
> falando que é atômico). Tem certeza que vc não está confundindo sessão
> com conexão?
>
> O que é uma transação pra vc? Não entendi esse termo.
>
> Como disse o Eden, o HTTP é stateless e o mecanismo de sessão é uma
> abstração que serve pra indicar ao servidor que várias requisições
> distintas, ou seja, não atômicas, pertencem a um mesmo contexto.
>
> Aliás o reaproveitamento de conexão é algo que só existe a partir do
> HTTP/1.1, ou seja, se o servidor falar HTTP/1.0, independente do que
> você faça, vc vai necessariamente abrir uma nova conexão para cada
> requisição.
>
> > No lado cliente precisa tudo ser controlado pelo mesmo processo? Não
> > necessariamente, vai da necessidade de cada transação.
>
> Não entendi.
>
> Até bem pouco tempo todos os browsers processavam várias 'transações'
> em um único processo. Qual o problema?
>
> > Não sei se faz mais sentido agora. Acho que ficou bizarro quando entrou o
> > IPC na história... :)
>
> Pra mim não tá fazendo sentido nenhum misturar IPC com cliente de web
> site. Ajude-me a te ajudar.
>
> Pelo que eu entendi vc precisa acessar um site de um fornecedor e
> interagir com ele. O normal é criar um user agent, submeter
> requisições e tratar as respostas. Nada de IPC, a menos que vc tenha
> algo muito específico. É isso?
>
> Dê uma olhada no link abaixo e vamos tentar sincronizar a conversa.
> Acho que estamos falando de coisas diferentes.
> https://github.com/blabos/Docs/wiki/Protocolo-HTTP
>
>
>
> 2011/7/27 Kojo <rbsnkjmr at gmail.com>:
> > O que estou tentando resolver é justamente o compartilhamento de sessão
> > entre diferentes processos.
> > Vou explicar o cenário e dar um exemplo.
> > Cenário:
> > Tenho um fornecedor que disponibiliza o serviço via web site.
> > Exemplo:
> > Veja bem, é só um exemplo. Imagine uma livraria pela Internet, que
> compra,
> > vende, tem um chat, divulgação de notícias etc, e ele é o seu fornecedor.
> > Vc quer se conectar ao sistema dele e automaticamente, comprar, vender,
> > acompanhar o bate-papo, ver as notícias etc...
> > Para cada transação vai abrir uma sessão? Não necessariamente. O HTTP é
> > atômico, e para otimizá-lo existe o reaproveitamento de sessão na camada
> de
> > aplicação para ser reaproveitado em diferentes transações.
> > No lado cliente precisa tudo ser controlado pelo mesmo processo? Não
> > necessariamente, vai da necessidade de cada transação.
> > Não sei se faz mais sentido agora. Acho que ficou bizarro quando entrou o
> > IPC na história... :)
> > Obrigado pela indicação do livro, vou colocá-lo na lista.
> >
> >
> >
> >
> > Em 27 de julho de 2011 13:15, Blabos de Blebe <blabos at gmail.com>
> escreveu:
> >>
> >> Cara,
> >>
> >> Por que raios tem que ser a mesma sessão?
> >>
> >> Com as informações que você deu até aqui, o que vc quer fazer não faz
> >> o menor sentido.
> >>
> >> Me corrija se eu estiver errado: vc quer reaproveitar um mesmo user
> >> agent transacionando em uma mesma sessão só que em processos
> >> diferentes? Pra quê?
> >>
> >> Está me cheirando a confusão conceitual. Explique melhor qual o
> >> *problema* que vc está tentando resolver.
> >>
> >> Se você está tentando usar IPC eu imagino que você já leu o capítulo 14
> do
> >> apue:
> >>
> >>
> http://www.amazon.com/Programming-Environment-Addison-Wesley-Professional-Computing/dp/0201563177
> >>
> >> Partindo disso e sabendo como funciona o modelo de processo do UNIX,
> >> vc sabe que a menos que sua linguagem preferida possua um eval da
> >> vida, não dá pra executar código de um processo a partir de outro,
> >> certo? E que por isso IPC normalmente (ignore os exoterismos por
> >> enquanto) refere-se a troca de dados e soemtne dados, certo?
> >>
> >> Então, qual o problema que vc está tentando resolver?
> >>
> >> []'s
> >>
> >> 2011/7/27 Kojo <rbsnkjmr at gmail.com>:
> >> > Comentários em linha:
> >> >>
> >> >> Porque você não simplesmente passa um nome de arquivo explícito pro
> >> >> cookie jar do LWP, daí qualquer LWP que você criar passando esse
> >> >> arquivo
> >> >> ai ter o mesmo conjunto de sessões.
> >> >
> >> >  Kojo -> Vou testar isso. Se o LWP consegue manter tudo no cookie jar
> >> > vai
> >> > ser a melhor saída.
> >> >
> >> >>
> >> >> Apesar que nada disso deveria ser necessário, se você fizer um fork()
> >> >> no
> >> >> processo (que é o que o IPC::Lite faz por trás das cenas), o objeto
> LWP
> >> >> é copiado automaticamente pra você, com a sessão e tudo. Explica
> melhor
> >> >> o teu requisito, porque pelo que você falou até agora, não tem
> >> >> necessidade de usar o Data::Dumper.
> >> >
> >> > Kojo -> Eu pensei nessa possiblidade, mas veja só, um dos processos
> que
> >> > reaproveitaria o LWP via IPC é disparado via crontab. Para eu rodar
> esse
> >> > processo via fork a partir do processo que inicializa o LWP, eu teria
> >> > que
> >> > implementar um "crontab" na mão para rodar o processo filho nos
> horarios
> >> > determinados. Eu até procurei umas libs para isso, mas sujaria muito a
> >> > solução.
> >> > O Data::Dumper era só para serializar o LWP para passar via IPC::Lite,
> >> > que
> >> > não consegue passar objetos.
> >> > Vou testar o cookie jar hoje a noite, e posto o resultado...
> >> >
> >> >>
> >> >> --
> >> >>   Eden Cardim       Need help with your Catalyst or DBIx::Class
> >> >> project?
> >> >>  Code Monkey                    http://www.shadowcat.co.uk/catalyst/
> >> >>  Shadowcat Systems Ltd.  Want a managed development or deployment
> >> >> platform?
> >> >> http://blog.edencardim.com/
> >> >>  http://www.shadowcat.co.uk/servers/
> >> >> http://twitter.com/#!/edenc
> >> >> =begin disclaimer
> >> >>   Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
> >> >>  SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org
> >> >>  L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
> >> >> =end disclaimer
> >> >
> >> >
> >> > =begin disclaimer
> >> >   Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
> >> >  SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org
> >> >  L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
> >> > =end disclaimer
> >> >
> >> >
> >> =begin disclaimer
> >>   Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
> >>  SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org
> >>  L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
> >> =end disclaimer
> >
> >
> > =begin disclaimer
> >   Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
> >  SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org
> >  L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
> > =end disclaimer
> >
> >
> =begin disclaimer
>   Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
>  SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org
>  L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
> =end disclaimer
>



-- 
Renato Santos
http://www.renatocron.com/blog/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/saopaulo-pm/attachments/20110727/30d4366f/attachment-0001.html>


More information about the SaoPaulo-pm mailing list