[SP-pm] IPC / Data::Dumper

Wed Jul 27 13:26:01 PDT 2011

Pessoal,
a conversa ficou meio maluca. No começo eu não deixei muito claro qual era o
propósito, mas depois só não entendeu quem não quis.

Eu preciso compartilhar uma sessão de browser, só isso. E vai funcionar o
cookie jar, pois me lembrei que já fiz testes compartilhando o arquivo de
cookie do Firefox com o LWP.

Como eu já expliquei, eu estava tentando resolver com IPC pq é algo que acho
melhor do que persistir estruturas de dados/objetos em disco, mas tinha me
esquecido que o LWP já trabalha nesse esquema.  O IPC com certeza vai me
servir para outras coisas, mas felizmente ou infelizmente não serviu para o
LWP, pq o objeto é muito complexo.

A primeira resposta do Stanislaw em modo Gambiarra ON ilustra muito bem essa
passagem de objetos entre diferentes processos, e funciona com coisas
simples. É inseguro, mas pode ser adequado para alguns processos específicos
em ambiente controlado.

E podem ficar despreocupado que a intenção não é sobrecarregar servidor de
fornecedor nenhum, é só agilizar alguns processos. Agradeço as respostas,
todas foram de grande valor.

2011/7/27 Renato Santos <renato.cron at gmail.com>

> 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/
>
> =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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/saopaulo-pm/attachments/20110727/c47cd8f2/attachment.html>