Alternativas ao socket

[Gustavo Cruz]

Olá pessoal,

Temos um sistema atualmente que efetua troca de mensagens via socket entre cliente e servidor. Basicamente temos um servidor virtualizado (com N VMs) e um server que recebe as mensagens via socket destes client´s (VMs) e dispara outras mensagens para essas, também via socket. Ou seja, existe a necessidade do tráfego de ambos os lados.

Ultimamente tenho presenciado alguns problemas na desserialização destes pacotes, uma vez que o protocolo TCP trabalha via streaming e não garante a integridade do pacote. Só que o sistema não foi construído anteriormente pensando nisso e o problema com perdas só aumentado. Daí a tarefa da equipe pensar em uma solução que resolva o problema ou que substitua a comunicação via socket.

A mensagem que é trocada é basicamente um XML que contêm informações sobre o estado atual do cliente, além de outras instruções, como ações para este que são disparadas pelo servidor, baseado na condição atual do client. (ambas as aplicações, cliente e servidor, são winforms)

Dei uma pesquisada e vi que o WCF pode ser uma boa opção, mas como diz o ditado, "bebê que não chora não mama", de repente alguém da lista já trabalhou com estrutura de messaging e tem algumas dicas a passar :-)

[Breno Ferreira]

"... uma vez que o protocolo TCP trabalha via streaming e não garante a integridade do pacote"

Como assim, não garante integridade? Que eu saiba, uma das principais vantagens do TCP (ao contrário do UDP, por exemplo) é garantir integridades no envio dos pacotes. Para isso existems os ACKs no header dos pacotes e ainda existem checksums e CRCs para evitar erros de transmissão.

Tem certeza que o problema está no uso de TCP Sockets, e não tem outra causa?

Abs

Breno Ferreira
Twitter: @breno_ferreira
Blog: http://brenoferreira.wordpress.com

---

From: gfcm...@gmail.com
Date: Thu, 17 Jan 2013 10:08:07 -0200
Subject: [dotnetarchitects] Alternativas ao socket
To: dotnetar...@googlegroups.com

--
Você recebeu esta mensagem porque faz parte do grupo .Net Architects hospedado no Google Groups.
Para postar envie uma mensagem para dotnetar...@googlegroups.com
Para sair do grupo envie uma mensagem para dotnetarchitec...@googlegroups.com
Para mais opções visite o grupo em http://groups.google.com/group/dotnetarchitects?hl=pt-br

[Daniel Franzini]

Uma possibilidade é usar sistemas de trocas de mensagens como o ZeroMQ.

2013/1/17 Gustavo Cruz <gfcm...@gmail.com>

--
Você recebeu esta mensagem porque faz parte do grupo .Net Architects hospedado no Google Groups.
Para postar envie uma mensagem para dotnetar...@googlegroups.com
Para sair do grupo envie uma mensagem para dotnetarchitec...@googlegroups.com
Para mais opções visite o grupo em http://groups.google.com/group/dotnetarchitects?hl=pt-br

--
Daniel

"Let us change our traditional attitude to the construction of programs. Instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a computer to do." (Donald Knuth)

"Yes, technogeeks can be funny, even if only to each other." (http://www.boogieonline.com/revolution/science/humor/)"

"Man is driven to create; I know I really love to create things. And while I'm not good at painting, drawing, or music, I can write software." (Yukihiro Matsumoto, a.k.a. ``Matz'')

[Jornando Junior]

perda de pacote normalmente é um problema na infra-estrutura de rede e não na aplicação.

__________________________________________________

[Gustavo Cruz]

Na verdade eu quis dizer que não garante a integridade de pacotes únicos no send e receive. Algo do tipo, se envio "Paulo" e depois "Antonio", a mensagem pode chegar de N maneiras do outro lado. Pode chegar "PauloAntonio" por exemplo...

2013/1/17 Breno Ferreira <bfer...@windowslive.com>

[Gustavo Cruz]

Daniel, nunca ouvi falar no ZeroMQ., sinceramente não tenho muito conhecimento em messaging. Quais vantagens ele poderia me oferecer, neste caso? Vou dar uma olhada no projeto...

2013/1/17 Jornando Junior <jornand...@gmail.com>

[Gustavo Cruz]

Luiz, acredito que uma solução  voltada para messaging seria mais ideal, mas talvez o WCF atenderia sim. 

Essa é a minha dúvida. A questão é que preciso de muita disponibilidade e controle entre as aplicações. Temos um server que comunica com o client, e o client que comunica com uma outra aplicação, dentro da mesma estação. E o caminho inverso também. Sendo que qualquer uma delas pode ficar indisponível por algum tempo.....

Sei que WCF poderia atender, mas ainda não consegui visualizar como o utilizaria neste cenário....

2013/1/17 Luiz Carlos Faria <luizcar...@gmail.com>

Há a necessidade de trabalhar em tão baixo nível? Um WCF não atenderia?

Questiono pois tudo o que vc citou como problema, sequer existe no WCF e é friendly para desenvolver. 

O chato de socket é ter de se preocupar com seu protocolo, qualquer um mecanismo de exposição mais alto nível resolve tudo isso de forma simples.

[Luiz Carlos Faria]

Como o WCF pode abstrair o protocolo em si, você poderia usar MSMQ para a comunicação. 

Dá uma olhada nos links

http://www.israelaece.com/post/WCF-MessageQueue.aspx

http://technet.microsoft.com/en-us/library/cc723251.aspx

[Fabio Rodrigues e Souza]

Caso queira uma solução Messaging, talvez isso ajudaria, já trabalhei e recomendo:

http://activemq.apache.org/

Mas consideraria usar o WCF, poderia sanar bem esse problema..

[Victor Arias]

Você está fazendo tudo isso errado... você de fato quer mensageria, não sockets tcp...

Caso queira continuar usando sockets, por favor: http://lmgtfy.com/?q=protocol+buffers+.net

[]s,

Victor Arias

[Winston Pacheco Junior]

Cara, isso se resolve com um terminador para cada mensagem.
Trabalho com um sistema que tem uma arquitetura similar a sua. Resolvemos esse problema da "separação" das mensagens dessa forma.

[André Körbes]

Gustavo

Vc está confundindo as coisas em relação ao TCP.

O TCP garante duas coisas: ordem e integridade. Ou seja, se vc mandar "Paulo" e depois "Antonio", as duas vão chegar, e nessa ordem.

O que é permitido acontecer, devido a bufferização, é as mensagens não chegarem do mesmo jeito que vc enviou, ou seja, poderia chegar: "PauloAn" e depois "tonio". Para isso geralmente se tem uma máquina de estado na recepção que controla se o seu pacote "lógico" foi recebido completamente.

André

[Luiz Carlos Faria]

[Gustavo Cruz]

@André...era exatamente isso que eu queria expor...me embolei nas palavras. Pelo que andei pesquisando, a ideia é sempre tentar conhecer o tamanho do pacote que se está recebendo, certo? Hoje o que tem, diria eu, foi construído de forma meio tosca, pois o receiver fica tentando desserializar a mensagem via try/catch...e só quando acha uma mensagem "desserializável" é que ele processa a requisição de fato. Ou seja, o buffer nesse caso vira um problema, pois a comunicação não garante os messages boundaries.  É essa máquina de estado na recepção que não tem hoje e que ferra com o processo. Sabemos que construir isso na ponta resolveria o problema, só que gostaríamos de saber se é o melhor a se implementar....

Como muitos falaram aí em cima, talvez uma solução básica de mensageria atenderia melhor ao negócio do que a comunicação via TCP. Já que vamos mexer, de repente evoluir para isso seja interessante, visto que temos abertura para isso.

2013/1/17 André Körbes <andre....@gmail.com>

[André Körbes]

oi Gustavo,

Se vc puder evitar mexer diretamente com socket e deixar isso a cargo de uma biblioteca/framework tipo WCF, geralmente é a melhor solução. Especialmente porque parece que a implementação de uma máquina de estado seria complicada no "protocolo" que vc tem hoje, e vc controla o sistema todo, ou seja, não é uma integração com um sistema de terceiros.

André

[Eric Lemes]

Gustavo,

Praticamente todas as tecnologias de integração usam TCP por baixo dos panos. É possível que existam bugs no código pra ter perda de mensagens.

É importante também conhecer os teus requisitos.  Trocando a tecnologia de integração vc pode ganhar em.simplicidade. no código mas perder em desempenho.

Dá uma olhada no.meu blog: http://ericlemes.com

Tem uma série sobre integração,  com uma pancada de métodos diferentes, comparativos de desempenho e exemplos de código. 

Abraços

Eric

[Gustavo Cruz]

Valeu, vou dar uma olhada.

Achei também um artigo interessante no site do Elemar também sobre MSQM, e estou lendo também sobre o MassTransit....! 

@Eric, valeu pela indicação, vou olhar seu blog sim!

2013/1/17 Eric Lemes <eric...@gmail.com>

[Denis Bittencourt Muniz]

Lendo rapidamente, tenho uma visão: você precisa trafegar mensagens pela rede, em determinado(s) protocolo(s). O WCF vai atender muito bem essa demanda, acredito ser a melhor solução, como foi sugerido já pelo pessoal aqui nesse tópico. A ideia de socket's acredito ser trabalhosa no cenário que você precisa (inclusive, qual o volume de dados, trafego, estamos falando?).

Por fim, para tratar indisponibilidade de serviços, sincronismo de mensagens e outras questões de comunicação, um sistema de mensageira seria o ideal... (de mensageiria, falo com menos propriedade, em relação ao serviço)

Experimente o mais simples: WCF+MSMQ (integração entre tecnologias Microsoft), depois olhe outras alternativas, como ZeroMQ, a medida que sentir mais confortável com o cenário (e solução) de trabalho.

Att,

Denis

[Felipe Oliveira @scaphe]

Olá Gustavo, 

Li toda a Thread. Para você garantir a ordem exata de maneira simples, existe uma Spec dentro dos WS* /Reliable Message. O provider WCF faz a implementação da mesma - http://msdn.microsoft.com/en-us/library/aa480191.aspx. 

Diria que você poderia ter uma solução com os Endpoints via Serviço, utilizando o WCF + AzureService Bus com Relay, para não ter que mudar nada na sua infraestrutura interna. Ele trabalhará normalmente com TCP e você não precisará abrir nenhuma porta especial no seu firewall. 

[Felipe Oliveira @scaphe]

Só um adendo, talvez nem precise se preocupar com Reliable, já que o AzureService Bus vai implementar o FIFO - (First In, First Out) nas suas mensagens, então vai estar na ordem e por baixo ele garante a entrega. 

Um abraço, 

Felipe.