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

Ulisses-IBIZ ulisses at ibiz.com.br
Tue May 3 14:18:40 PDT 2011


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


More information about the SaoPaulo-pm mailing list