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 <[email protected]> > > 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 <[email protected]>: > > 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 <[email protected]> > 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 <[email protected]>: > >> > 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: [email protected] > >> >> 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: [email protected] > >> > 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: [email protected] > >> 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: [email protected] > > 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: [email protected] > 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: [email protected] L<http://mail.pm.org/mailman/listinfo/saopaulo-pm> =end disclaimer
