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).
[quote=peczenyj]mais rapido depende de muitas coisas.
O udp é um protocolo diferente, muita coisa teria que ser feita na camada de aplicação…
http://pt.wikipedia.org/wiki/Protocolo_UDP[/quote]
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…