[SP-pm] Socket - algumas questões:

Andre Carneiro andregarciacarneiro at gmail.com
Sat May 21 15:20:20 PDT 2011 

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

More information about the SaoPaulo-pm mailing list