Arquivo Discussoes de Programacao e Tecnologia 
Pessoal qual os melhores parametros para conexão via socket…
socketCliente.setKeepAlive(true);
socketCliente.setTcpNoDelay(true);
socketCliente.setPerformancePreferences(10,11,11);
socketCliente.setReceiveBufferSize(500);
socketCliente.setSendBufferSize(500);
socketCliente.setTrafficClass(255);
Alguém tem ideia?
Depende da aplicação. Que tipo de dado vc vai trafegar? Grande? Pequeno? Fragmentado? Em rede local? Internet? Em que volume? A máquina que receberá processa os dados lentamente? E a que envia?
Normalmente eu só mexo no “setTcpNoDelay” e olhe lá. Se você está com problemas no seu protocolo, não é mexer nas opções que vai resolver seu problema.
Faço minhas as palavras do Thingol.
Mas já tive que mexer no receive buffer uma vez, mas provisoriamente, até otimizarmos uns trechos de códigos feios na aplicação cliente.
Certo ViniGodoy… e thingol…
A minha aplicação é um chat via socket… e esta meio lento, não sei se é pór causa da internet… mas na rede local trafega em tempo real…
Coloquei o send e o receive buffer, por posso transferir arquivos via socket então mando sempre bytes de 500 e fica legal a velocidade da transferencia, as outras coisa nem sei pra que serve…
Na verdade é assim quando eu coloquei as outras opções, perforance, trafic, keepalive, vi que melhorou a velocidade da transferencia de arquivos
“chat via socket” - argh…
De qualquer maneira, uma das coisas que pode atrapalhar um pouco é que a latência na Internet é realmente grande se você usar uma conexão 3G ou EVDO (ou seja, via celular ou Embratel Livre). Via ADSL é um pouco menor.
Outra coisa que atrapalha é você mandar alguma coisa e ficar esperando a resposta. Isso realmente é lento mesmo. Dentro da medida do possível, evite esse tipo de protocolo “half-duplex” (onde você manda alguma coisa e espera que o outro lado responda.)
Porque thingol? não recomenda, qual a melhor maneira de desenvolver um chat?
Essa questão de “half-duplex” cuidei bastante e não tem no meu sistema… o duro mesmo é a lentidão do socket…
Não poderia ser feito usando UDP ?
peczenyj… isso ficaria mais rapido?
Porque nós tenho a mesma aplicação com webservice ambas rodam no mesmo servidor que não nada instalado e fica mais lento que com webservice…
mais rapido depende de muitas coisas.
O udp é um protocolo diferente, muita coisa teria que ser feita na camada de aplicação… 
É que “chat via socket” normalmente não funciona muito bem se você tem aqueles famosos problemas de ter que usar a Internet em algum lugar que tem um daqueles proxies ou firewalls que bloqueiam tudo, exceto a porta 80 ou 443. O Gmail chat, por exemplo, é meio lerdinho mas não tem esse problema (só que depende de um servidor, é claro).
mais rapido depende de muitas coisas.O udp é um protocolo diferente, muita coisa teria que ser feita na camada de aplicação…
Essa é uma daquelas referências da wiki em que eu tenho certeza de que pelo menos um dos autores sabia do que estava falando.
Cuidado que no chat via UDP, vc deve pelo menos garantir que o pacote chegou do outro lado.
Certo…
Mas assim thingol é lerdo mesmo chat via socket, não tem como melhorar isso? questão de proxies e firewalls fiz um implementação que libera o meu acesso aqui pelo sistema… funciona bem com webservices…
Que tipo de protocolo vcs recomendão para fazer um chat e ficar rapido? RMI?
tem alguma forma de minimizar esta lentidão?
se vc acha que o problema é rede, faça um teste.
abre um socket e manda um ‘asdasdasdasdasdasdasdasdasdas + tempo em milisegundos’ gigante pro cliente e la grava q horas foi recebido.
analisa os pacotes de rede com um tcpdump da vida.
etc.
Bom vou tentar fazer isso para verificar se é o servidor… vou tbm tentar trocar de servidor
O ideal, para se ter medições mais precisas é calcular o Roundtrip time.
Ou seja, fazer o seu cliente devolver exatamente a mesma string, e calcular o tempo de ida-e-volta.
Isso pq o relógio das duas máquinas não será sincronizado.
Cara, não tem como disfarçar lag, já que não tem como vc fazer os dados correrem “mais rápido”. Pelo menos, não numa aplicação tão simples e determinística como um chat. Você pode mandar pacotes de texto menores, para que o usuário do outro lado da linha veja o texto sendo digitado, e com isso fique disposto a esperar mais tempo.
Mas não dá para fazer muito melhor do que isso não.
O problema do lag na internet não é processamento, mas a rota que os pacotes toma. O seu servidor é muito distante (fora do Brasil, por exemplo)? Se for, troque por um server nacional que já deve dar uma boa atenuada.
ViniGodoy, o que você falou tem sentido questão de enviar por pacotes…
Mas o meu servidor é nos EUA e tenho um no brasil… mas o do brasil não chega nem as pés dos que tenho no EUA… o link lá dos EUA é de 100 mega bits… e aqui do brasil é bem fraquinho somente para hospedagem de alguns sites…
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.
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:
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?