Melhores parametros para conexão via socket

Não confunda. Banda não tem nada a ver com atraso (a menos que ela falte, lógico).
Mas é importante entender que são dois parâmetros diferentes na rede e, para aplicações com feedback visual (chat e jogos included), geralmente o lag é o parâmetro mais importante deles.

O seu problema está muito longe de ser banda. O fato é que o caminho que os pacotes percorrem daqui até lá é maior, e pode conter conexões mais lentas do que daqui até aqui mesmo. :wink:

Olá

Não!!!

Experimente usar o exemplo de chat que já vem pronto no Grizzly. Baixe o Grizzly e baixe o exemplo de chat.

Outra opção seria fazer como o GTalk. Baixe o ejabberd de http://www.process-one.net/en/ejabberd/downloads

ejabberd = instant messaging server, licensed under GPLv2 (Free and Open Source), written in Erlang/OTP. Among other features, ejabberd is cross-platform, fault-tolerant, clusterable and modular.

[]s
Luca

A única coisa que pode resolver o problema é os seguinte:

  1. Rastreie todos os pontos que os pacotes trafegam entre a origem e o destino. Você pode fazer isso usando comandos como tracert. Não esqueça de rastrear possíveis rotas alternativas;
  2. Dê de presente uma boa infraestrutura de rede para cada um desses pontos. Compre bons roteadores e use preferencialmente fibra ótica.
  3. Certifique-se de não mudar suas máquinas de lugar, senão vc vai ter que voltar ao passo 1.

Achou inviável? Eu também.

A segunda alternativa é deixar o servidor o mais próximo possível de seus clientes. Afinal, com menos locais para os pacotes de rede saltarem, haverá menos chances deles passarem por infraestrutura ruim no caminho.

Aplicações como as que o Luca sugeriu fazem isso. A idéia de fazer clusters é justamente distribuí-los geograficamente. Assim uma aplicação grande, poderia ter vários servidores interconnectados e em diferentes locais, permitindo uma conexão mais rápida de quem estiver próximo deles.

A infra-estrutura entre os servidores muitas vezes pode ser garantida, caso vc seja grande e poderoso o suficiente, e possa pagar por isso.

A terceira opção é fornecer mais feedbacks para seu usuário, e esperar que todos convivam com o problema.

Isso é totalmente inviavel… hehehehehehe

Na verdade é assim, eu tenho essa aplicação rodando em webservices… e ela come muita banda e tbm é meio lento… a solução que eu encontrei foi fazer via socket para não comer tanta banda e comunicar com a aplicação somente quando necessario… mas ficou um pouco a mesma lentidão que no webservice… porém come menas banda…

Como funciona esse “Grizzly” eu terei que montar o server igual ao socket? eu terei como auditorar os dados que trafegarem pelo server?