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