Image Image Image Image Image
Scroll to Top

Topo

servidor

20

maio
2012

Sem Comentários

Em Blog
Ruby

Por Allison

Como implementar uma aplicação Cliente-Servidor com Sockets em Ruby

Em 20, maio 2012 | Sem Comentários | Em Blog, Ruby | Por Allison

Fonte: Samuel Vinicius/IMasters

Este é primeiro de vários artigos que irei publicar sobre Sockets em Ruby. Mas, antes de qualquer coisa, é conveniente dizer o que são Sockets:

A grosso modo, são as extremidades de um canal de comunicação bidirecional. Ou seja, você pode utilizar Sockets para fazer comunicação entre processos de uma máquina, entre máquinas diferentes e entre processos de máquinas diferentes.

O que iremos fazer?

Como este é o primeiro artigo sobre o tema, pretendo ir direto ao ponto, mostrando de forma simples como implementar uma aplicação Cliente-Servidor. Nessa aplicação, o cliente envia uma mensagem para o servidor e este responde, sendo a comunicação entre cliente e servidor realizada via Socket através do protocolo TCP.

Então, sem mais delongas, vamos aos códigos:

  • Servidor
 
# file server.rb
require 'socket'
 
server = TCPServer.open(3001)  # Abre socket em escuta na porta 3001
loop { # o servidor nunca morre, fica sempre executando
client = server.accept      # aceita conexão do cliente
msg_cliente = client.recvfrom( 10000 ) # recebe mensagem - 10000 bytes - do cliente
 
puts  "Mensagem do cliente: #{msg_cliente}" # imprime a mensagem do cliente no servidor
client.puts "Ola cliente eu, o servidor, recebi sua mensagem" #envia uma mensagem ao cliente
client.close # fecha conexão
}
  • Cliente
# file client.rb
require 'socket'
 
server = TCPSocket.open('localhost', 3001) # conecta ao servidor na porta 3001
server.puts "Ola servidor eu, o cliente, estou enviando uma mensagem" # envia mensagem para o servidor
 
resp = server.recvfrom( 10000 ) # recebe a mensagem -10000 bytes - do servidor
puts resp
 
server.close # Fecha a conexão com o servidor

Como rodar a aplicação?

Primeiro, salve o código do servidor em um arquivo .rb (por exemplo server.rb) e execute o arquivo – ruby server.rb. Nesse ponto, o servidor está esperando a conexão de um cliente. Agora salve o código do cliente de forma análoga e execute em outro terminal, de modo que cliente e servidor sejam rodados ao mesmo tempo. A partir de então, o cliente envia uma mensagem ao servidor e o servidor responde.

Este é um exemplo simples do que pode ser feito com Sockets. Espero que te ajude em algo.

***

Referência: http://www.tutorialspoint.com/ruby/ruby_socket_programming.htm

Tags | , , , ,

10

abr
2012

Sem Comentários

Em Blog
Rails
Ruby

Por Allison

Puma, novo servidor web para Ruby, é disponibilizado

Em 10, abr 2012 | Sem Comentários | Em Blog, Rails, Ruby | Por Allison

Fonte: IMasters

Com informações de The H

A especialista em Ruby on Rails Platform-as-a-Service, Engine Yard, divulgou um novo servidor web para Ruby, que recebeu o nome de Puma. De acordo com seus desenvolvedores, o Puma foi criado como uma alternativa para WEBrick e Mongrel, e foi construído para ter melhor desempenho e para lidar com concorrência.

A novidade trabalha com qualquer aplicativo que suporte a interface Rack, além de processar requisições usando o Ragel, uma extensão otimizada em C, que oferece rápida análise do protocolo HTTP 1.1, atrás do qual oferece a solicitação em uma thread a partir de uma pool de threads. O Puma foi feito para ser um servidor “go-to” para Rubinius, e também trabalha com JRuby and Ruby MRI.

Mais informações sobre o Puma, incluindo um guia e benchmarks, podem ser encontrados no site do projeto e neste link. O código fonte do novo servidor web está hospedado no GitHub.

Tags | , , ,

27

mar
2012

Sem Comentários

Em Blog
SQL

Por Allison

SQL Server 2012: Grandes melhorias no T-SQL

Em 27, mar 2012 | Sem Comentários | Em Blog, SQL | Por Allison

Fonte: Jonathan Allen , traduzido por Mário Henrique/InfoQ

O dialeto SQL do SQL Server 2012, o Transact-SQL, vem com melhorias importantes, incluindo suporte para funções ANSI FIRST_VALUE e LAST_VALUE, paginação de resultados de alto nível usando FETCH e OFFSET e suporte a funções de parsing e de formatação do .NET.

Fetch e Offset

Atualmente, muitos desenvolvedores de SQL Server que desejam implementar paginação de resultados no lado do servidor precisam utilizar técnicas “imperativas” de programação, como carregar os resultados em uma tabela temporária, numerar as linhas e então selecionar o intervalo de interesse. Há também desenvolvedores que utilizam ROW NUMBER e OVER; outros utilizam cursores.

O SQL Server 2012 resolve essa limitação e permite mais consistência no uso, adicionando suporte declarativo para a paginação de resultados, através das novas opções OFFSET e FETCH NEXT do Transact-SQL. Mas note que atualmente não há otimização de performance; o SQL Server está fazendo a mesma coisa que os desenvolvedores fariam manualmente.

Clause Windowing

Às vezes, os desenvolvedores precisam escrever consultas que identificam diferenças entre linhas. Por exemplo, pode-se estar interessado na quantidade de tempo entre o timestamp de uma linha e outra. Isso é fácil de fazer utilizando cursores, mas o desempenho e elegância dessa solução deixam a desejar. É possível ainda utilizar uma subquery executada linha a linha, mas isso é extremamente custoso. Pode-se ainda implementar tudo no lado do cliente mas isso não funcionaria se o cliente for uma ferramenta de geração de relatórios, por exemplo.

No SQL Server 2012, agora é possível acessar diretamente a linha anterior utilizando a função LAG. O analisador de consultas SQL retém a linha anterior na memória, de forma que não há necessidade de uma subquery. Isso resulta em melhor desempenho. A função LAG aponta para a linha anterior, mas é possível utilizar um offset para ter acesso a linhas anteriores. A função LEAD é equivalente a LAG, mas trabalha com linhas posteriores à que está sendo lida. As funções LAG e LEAD, que são parte do padrão ANSI, eram um pedidas pelos desenvolvedores desde a implementação da sintaxe OVER no SQL Server 2005. As funções FIRST VALUE e LAST VALUE também estão disponíveis no SQL Server 2012.

Reflection

Anteriormente, para testar quais os resultados seriam retornados por stored procedures ou consultas SQL, utilizava-se o comando SET FMTONLY. Esse comando permitia aos desenvolvedores visualizar as colunas retornadas, sem a necessidade de executar uma consulta SQL. Mas a informação se limitava apenas às definições das colunas resultantes da execução da consulta.

Com a nova procedure sp describe first result set, os desenvolvedores podem obter informações detalhadas a respeito de quais resultados seriam retornados pela consulta. Essas informações incluem tipos de dados, tabelas ou colunas-fonte e outras informações importantes, também disponíveis nas telas de gerenciamento dinâmico, sys.dm exec describe first result e sys.dm exec describe first result set.

Código Defensivo

Tradicionalmente, os desenvolvedores ficam à mercê de seus colegas quando utilizam stored procedures. Sem garantias em relação ao que será retornado, falhas acidentais se tornam uma preocupação. O T-SQL não oferece formas de prevenir esses erros, mas é possível minimizá-los utilizando a opção RESULT SETS.

Quando usada, a opção RESULT SETS faz com que a procedure armazenada retorne uma estrutura específica de dados. Se os resultados da procedure forem diferentes do requisitado, a opção retorna um erro. Considerando que se trata de um erro em tempo de de execução, recomenda-se aos desenvolvedores que utilizarem essa opção se assegurem de que os erros sejam depurados antes do código ir para produção.

Tratamento de Erros

O T-SQL tem suporte para TRY-CATCH desde 2005, porém o suporte THROW não existia até agora. Sem argumentos, THROW funciona da mesma maneira que em C# ou VB. Isto é, THROW retorna uma exceção e mantém o log de informação capturada sobre o erro, o que é muito útil.

Quando utilizada com argumentos, THROW é similar à RAISERROR, exceto por não suportar números de erros em sys.messages e a severidade é sempre 16. Além disso, os erros não detectados por THROW sempre terminam a execução.

Parsing e Conversões

O T-SQL agora suporta a função PARSE que inclui a opção de especificar uma “culture”. Esta deve contar com suporte pelo framework .NET. Há também uma nova função TRY_CONVERT que, assim como TRY_PARSE, retorna null quando a conversão falha. Já a função FORMAT utiliza a formatação de strings do .NET. Apesar de mais lenta que as funções nativas como STR, é mais flexível.

Funções de Data e Hora

O processamento de data e hora no T-SQL recebeu melhorias. A função EOMONTH retorna o último dia do mês, dado importante para relatórios. As funções xxxFROMPARTS permitem construir valores de data/hora utilizando um conjunto de parâmetro em vez de apenas uma string. Há suporte para os tipos de dados Date, DateTime, DateTime2, DateTimeOffset, SmallDate e Time.

Outras funções

A função Choose do Access e Visual Basic agora está presente no T-SQL. Sob determinadas circunstâncias, pode ser utilizada como uma versão simplificada de CASE. Também está presente a função IIF.

A função CONCAT pode ser utilizada para concatenar strings. Além de tornar mais fácil a portabilidade de código de outras linguagens, essa função possui um tratamento de exceção diferente do operador +. Itzik Ben-Gan escreve:

O operador + de concatenação devolve NULL para inputs NULL. A função CONCAT converte inputs NULL em strings vazias antes da concatenação. Embora esta não seja uma boa solução, é possível fazer a mesma coisa utilizando a função COLAESCE, substituindo entradas NULL por strings vazias.

Tags | , , , ,

20

mar
2012

Sem Comentários

Em Blog
Ruby

Por Allison

Como implementar uma aplicação cliente-servidor usando Sockets em Ruby

Em 20, mar 2012 | Sem Comentários | Em Blog, Ruby | Por Allison

Fonte: Samuel Vinicius/IMasters

Referência: http://www.tutorialspoint.com/ruby/ruby_socket_programming.htm

Este é primeiro de vários artigos que irei publicar sobre Sockets em Ruby. Mas antes de qualquer coisa, é conveniente dizer o que são Sockets:

A grosso modo, são as extremidades de um canal de comunicação bidirecional. Ou seja, você pode utilizar Sockets para fazer comunicação entre processos de uma máquina, entre máquinas diferentes e entre processos de máquinas diferentes.

O que iremos fazer?

Como este é o primeiro artigo sobre o tema, pretendo ir direto ao ponto, mostrando, de forma simples, como implementar uma aplicação cliente-servidor. Nela, o cliente envia uma mensagem para o servidor e este responde. Sendo a comunicação entre cliente e servidor realizada via Socket, através do protocolo TCP.

Então, sem mais delongas. Vamos aos códigos:

Servidor

# file server.rb
require 'socket'

server = TCPServer.open(3001)  # Abre socket em escuta na porta 3001
loop { # o servidor nunca morre, fica sempre executando
client = server.accept      # aceita conexão do cliente
msg_cliente = client.recvfrom( 10000 ) # recebe mensagem - 10000 bytes - do cliente

puts  "Mensagem do cliente: #{msg_cliente}" # imprime a mensagem do cliente no servidor
client.puts "Ola cliente eu, o servidor, recebi sua mensagem" #envia uma mensagem ao cliente
client.close # fecha conexão
}

Cliente

# file client.rb
require 'socket'

server = TCPSocket.open('localhost', 3001) # conecta ao servidor na porta 3001
server.puts "Ola servidor eu, o cliente, estou enviando uma mensagem" # envia mensagem para o servidor

resp = server.recvfrom( 10000 ) # recebe a mensagem -10000 bytes - do servidor
puts resp

server.close # Fecha a conexão com o servidor

Como rodar a aplicação?

Primeiro, salve o código do servidor em um arquivo .rb – por exemplo server.rb – e execute o arquivo – ruby server.rb. Neste ponto, o servidor está esperando a conexão de um cliente. Agora salve o código do cliente de forma análoga e execute em outro terminal de modo que cliente e servidor sejam rodados ao mesmo tempo. A partir de então, o cliente envia uma mensagem ao servidor e o servidor responde.

Este é um exemplo simples do que pode ser feito com Sockets, espero que te ajude em algo.

Tags | , , , ,