[SP-pm] Socket - algumas questões:
Andre Carneiro
andregarciacarneiro at gmail.com
Sat May 21 15:21:55 PDT 2011
Falando em AnyEvent e implementação de servidores. Olha que legal...
http://search.cpan.org/search?query=AnyEvent+Server&mode=all
Cheers!
<http://search.cpan.org/search?query=AnyEvent+Server&mode=all>
Em 21 de maio de 2011 19:20, Andre Carneiro
<andregarciacarneiro at gmail.com>escreveu:
> Pois é pessoal. Por enquanto vou ficando com o AnyEvent mesmo.
>
> Fiz um esquema bem óbvio com o AnyEvent::Util, substituindo o fork() pelo
> fork_call e configurando os callbacks. Funcionou muito bem, e ficou bem
> fácil de tratar os sinais, além de ter reduzido o código significativamente.
> Eu vou postar a solução depois( não estou com ela aqui.. : - p )
>
> Desculpem pela demora no feedback.
>
> Obrigado pelas respostas!
>
>
> Cheers!
>
>
>
>
> Em 4 de maio de 2011 08:33, Andre Carneiro <andregarciacarneiro at gmail.com>escreveu:
>
> Entendi...
>>
>> Valeu Ulisses!
>>
>> Vou dar uma olhada com certeza!
>>
>>
>> Cheers!
>>
>>
>> 2011/5/3 Ulisses-IBIZ <ulisses at ibiz.com.br>
>>
>>> sendo rapido (sem tempo, me desculpe);
>>>
>>> se usei 'por anos' => serviu aos meus propositos e recomendo (mas cada um
>>> deve validar por si só) pela facilidade de adicionar hooks (suas subs) para
>>> configurar o que deve ser feito durante a conversa socket
>>>
>>> mais em http://search.cpan.org/~rhandom/Net-Server-0.99/lib/Net/Server. (veja
>>> HOOKS)
>>>
>>> usamos o Net::Server::Fork para receber requisicoes de cliente (eram
>>> transacoes contendo infos para busca em portais de validacao de credito PF e
>>> PJ), consulta via robo Web em portais pagos e nao pagos (Serasa, SPC,
>>> telefonicas, .....), montavamos um 'laudo de credito' e devolviamos a
>>> resposta no socket.
>>>
>>> la pelas tantas (depois de muito tempo) abandonamos o Net::Server::Fork e
>>> fizemos um bem enxuto (mais leve, rapido).
>>>
>>> control-freak manja? nao gosto de surpresas.....
>>>
>>>
>>> *From:* Solli Honorio <shonorio at gmail.com>
>>> *To:* saopaulo-pm at mail.pm.org
>>> *Sent:* Tuesday, May 03, 2011 5:53 PM
>>> *Subject:* Re: [SP-pm] Socket - algumas questões:
>>>
>>>
>>>
>>> 2011/5/3 Ulisses-IBIZ <ulisses at ibiz.com.br>
>>>
>>> Desculpa, mas sou meio lento ...
>>>
>>> Net::Server ja usei por anos.
>>>>
>>>
>>> ... isto significa que você recomenda, ou que você não recomenda ? Você
>>> poderia dar a sua 'revisão' sobre o módulo ?
>>>
>>>
>>>> AnyEvent nao conhecia.
>>>>
>>>>
>>>> *From:* Stanislaw Pusep <creaktive at gmail.com>
>>>> *To:* saopaulo-pm at mail.pm.org
>>>> *Sent:* Tuesday, May 03, 2011 4:57 PM
>>>> *Subject:* Re: [SP-pm] Socket - algumas questões:
>>>>
>>>> Existem outros frameworks, mais leves e mais específicos, tal como:
>>>> http://search.cpan.org/~rhandom/Net-Server-0.99/
>>>> E... BEWARE UDP!!! Tive oportunidade de presenciar pacotes sendo
>>>> perdidos e fora de ordem numa LAN, imagine em Internet!
>>>>
>>>> ABS()
>>>>
>>>>
>>>>
>>>> 2011/5/3 Andre Carneiro <andregarciacarneiro at gmail.com>
>>>>
>>>>> Oi Solli!
>>>>>
>>>>>
>>>>> Exatamente! Quando eu tento o raio do getline, ele não me traz nada
>>>>> apesar de escrever no socket, mas com certeza tem alguma coisa errada que eu
>>>>> não estou vendo. Talvez haja algum problema com a ordem que eu estou fazendo
>>>>> as coisas, sei lá. Vou dar uma fuçada no seu código e comparar as coisas pra
>>>>> descobrir.
>>>>>
>>>>>
>>>>> Sobre usar um framework, eu tô fazendo uns testes com o AnyEvent. Eu
>>>>> sinceramente acho POE muuuuito grande e complicado para o meu cérebro
>>>>> limitado. Já com o AnyEvent eu tô conseguindo me entender melhor.
>>>>>
>>>>>
>>>>> Sobre o livro, já tá na minha lista desse ano para comprar.
>>>>>
>>>>>
>>>>> Sobre usar UDP acho que não vale a pena por enquanto. Mesmo pq já tenho
>>>>> um deadline bem apertado pra entregar essa meleca. Então deixa pra lá.
>>>>> Talvez numa outra versão
>>>>>
>>>>>
>>>>> Thx a lot!
>>>>>
>>>>>
>>>>> Cheers!
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> 2011/5/3 Solli Honorio <shonorio at gmail.com>
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Uma das maneiras é assim :
>>>>>>
>>>>>> <code>
>>>>>>
>>>>>> #!/usr/bin/env perl
>>>>>> use strict;
>>>>>> use IO::Socket::INET;
>>>>>>
>>>>>> my $quit = 0;
>>>>>>
>>>>>> $SIG{INT} = sub { $quit++ };
>>>>>>
>>>>>> my $listen_socket = IO::Socket::INET->new(LocalPort => 2121,
>>>>>> Listen => 2,
>>>>>> Proto => 'tcp',
>>>>>> Reuse => 1,) or die "$!";
>>>>>>
>>>>>> while ( !$quit ) {
>>>>>> next unless my $connection = $listen_socket->accept;
>>>>>>
>>>>>> defined ( my $child = fork() ) or die "Can't fork: $!";
>>>>>>
>>>>>> if ( $child == 0 ) {
>>>>>> $listen_socket->close;
>>>>>> do_something($connection);
>>>>>> exit 0;
>>>>>> }
>>>>>>
>>>>>> $connection->close;
>>>>>>
>>>>>> }
>>>>>>
>>>>>> sub do_something {
>>>>>> my $socket = shift;
>>>>>>
>>>>>> $socket->autoflush(1);
>>>>>> $socket->print("Entre com os numeros para calculo:\n");
>>>>>>
>>>>>> while ( 1 ) {
>>>>>> my $input = $socket->getline();
>>>>>> exit 0 if $input =~ /quit/i;
>>>>>> $socket->print($input);
>>>>>> }
>>>>>>
>>>>>> }
>>>>>>
>>>>>> <code>
>>>>>>
>>>>>> O código acima é um echo server muito simples, que ilustra bem uma
>>>>>> comunicação bi-direcional. Não sei onde você está utilizando este código,
>>>>>> mas eu recomendo muito cuidado. Existem vários problemas com código deste
>>>>>> tipo (I/O Blocking, por exemplo) e uma enorme quantidade de coisas que podem
>>>>>> ocorrer de errado.
>>>>>>
>>>>>> Tenho um livro (Networking Programming with Perl) de 700 páginas só
>>>>>> falando de tudo que pode dar errado num código deste tipo e todas (ou quase)
>>>>>> variações de servidores escrito em Perl (tcp, udp, I/O Blocking, I/O
>>>>>> Nonblocking, forked, threaded). Utilizar print/getline, write/read,
>>>>>> syswrite/sysread é apenas o começo das perguntas de arquitetura que temos
>>>>>> que responder para um servidor.
>>>>>>
>>>>>> Se for possível, eu recomendo fortemente que você utilize um framework
>>>>>> para fazer isto, tipo o POE (
>>>>>> http://poe.perl.org/?POE_Cookbook/TCP_Servers tem um exemplo do mesmo
>>>>>> código que eu escrevi). Se não for possível, eu recomendo você dar uma
>>>>>> olhada no livro que eu disse (posso emprestar se for o caso). Temos também o
>>>>>> Mojolicious com os websocket (estou começando a ver isto), pode ser uma boa
>>>>>> alternativa.
>>>>>>
>>>>>> - Preciso de protocolo específico para fazer isso ?
>>>>>>>
>>>>>>
>>>>>> Uma conversa bi-direcional, você precisa definir os comandos que um
>>>>>> vai aceitar do outro. Você terá que criar algum protocolo de qualquer
>>>>>> maneira, uma linguagem que seja compreendida pelo servidor e cliente, qual
>>>>>> como o HTTP, FTP ou SMTP. Na transferência de arquivo, recomendo fortemente
>>>>>> no formato JSON. Aliais, este teu sistema não seria candidato para ser um
>>>>>> webapp com RESTfull web services implementado em Catalyst ou Mojolicious ?
>>>>>> Neste ambiente O URI é a função que recebe/retorna em JSON, sem view em html
>>>>>> !
>>>>>>
>>>>>>
>>>>>>> - Eu vi algumas pessoas usando udp ao invés de tcp alegando aumento
>>>>>>> de performance, mas abrindo mão de vários quesitos de segurança dentre
>>>>>>> outros problemas. Confirma?
>>>>>>>
>>>>>>>
>>>>>> Sim, o UDP é mais 'leve' do que o 'tcp'. Mas isto significa que você
>>>>>> terá que tratar tudo relacionado a transferência de dados (ordem dos
>>>>>> pacotes, perda dos pacotes, etc). Uma recomendação, a menos que você saiba
>>>>>> muito bem o que está fazendo, e que o consumo de rede seja justificado, não
>>>>>> utilize o UDP, o overhead para o programador não vale a pena. O HTTP utiliza
>>>>>> TCP e ninguém pensou em mudar isto, não siga os líderes :D ....
>>>>>>
>>>>>>
>>>>>>> Cheers!
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> André Garcia Carneiro
>>>>>>> Analista/Desenvolvedor Perl
>>>>>>> (11)82907780
>>>>>>>
>>>>>>> =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
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> "o animal satisfeito dorme". - Guimarães Rosa
>>>>>>
>>>>>> =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
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> André Garcia Carneiro
>>>>> Analista/Desenvolvedor Perl
>>>>> (11)82907780
>>>>>
>>>>> =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
>>>>
>>>>
>>>
>>>
>>> --
>>> "o animal satisfeito dorme". - Guimarães Rosa
>>>
>>> ------------------------------
>>>
>>> =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
>>>
>>>
>>
>>
>> --
>> André Garcia Carneiro
>> Analista/Desenvolvedor Perl
>> (11)82907780
>>
>
>
>
> --
> André Garcia Carneiro
> Analista/Desenvolvedor Perl
> (11)82907780
>
--
André Garcia Carneiro
Analista/Desenvolvedor Perl
(11)82907780
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/saopaulo-pm/attachments/20110521/506ad43d/attachment-0001.html>
More information about the SaoPaulo-pm
mailing list