ASM51

Olá,

Tenho uma aplicação em VB servidor TCP, utilizando o componente do windows, Winsock, funcioando perfeitamente bem com meus clientes(simuladores de conexão TCP), controlando, identificando e trocando mensagens entre as aplicações.

E outra aplicação desenvolvida em plataforma ARM que desempenha o papel do cliente, utilizando GPRS como meio de transmissão de dados e são vários.

Estou encontrando um situação muito peculiar e não tenho encontrado nenhum tópico relacionado.

Pelo servidor identifico que o mesmo cliente tem solicitado várias novas conexões TCP sem que haja um evento de desconexão. Com isso, não consigo gerenciar minhas conexões pois sempre que há uma nova conexão é do mesmo IP, gerando alocação desnecessária na memória do computador com índices de socket "inexistentes".

Existe alguma forma de identificar ou gerenciar conexões TCP sem que haja um evento de desconexão do cliente?

ola amigo, nao sei se entendi bem o que expos porque parece qu o caminho a seguir e' o'bvio:
- se o seu cliente solicita noba conexao sem ter necessidade ou caido a anterior o problema a ser tratado esta nele
- solicitacao de conexao sempre parte do cliente e o meio (gprs,...) nao tem nada a ver com isso a nao ser encaminhar o pedido
- se tem acesso ao programa server pode fazer com que ele negue novas conexoes de um ip que ja tenha uma conexao corrente

abraco

marcelo

Olá marcelo campos, obrigado pela resposta.

Era o que eu estava começando a concluir, porém penso se haveria alguma maneira de tratar tal situação no servidor.

Difícil negar a conexão quando existe um evento de conexão pois não tenho infomração ao endereço IP.

Eu havia feito de duas outras maneiras:
- Timer. Aceitando todas conexões e armazenando o último indeces de conexão do cliente. O timer verificaria estes indeces com socket aberto.
- KEEP ALIVE: Mandar uma mensagem de "KEEP ALIVE", por exemplo, para todos os indices abertos, e aquele com sem conexão daria erro na transmissão.

Em ambas situações não consegui o resultado esperado pois:
Timer: os indices ficam sempre abertos com o mesmo IP do cliente
KEEP ALIVE: como o índice (velho) armazena o IP do cliente, a mensagem é encaminhada para o cliente com IP ativo.

Acredito que este tipo de situação seja um tanto quanto incomum pois não encontro tópicos relacionados ao assunto.

Este comportamento tem impactado no servidor pois a cada nova requisição de conexão é alocado um socket na memória do computador.

Olá marcelo campos, obrigado pela resposta.

Era o que eu estava começando a concluir, porém penso se haveria alguma maneira de tratar tal situação no servidor.

Difícil negar a conexão quando existe um evento de conexão pois não tenho infomração ao endereço IP.

Eu havia feito de duas outras maneiras:
- Timer. Aceitando todas conexões e armazenando o último indeces de conexão do cliente. O timer verificaria estes indeces com socket aberto.
- KEEP ALIVE: Mandar uma mensagem de "KEEP ALIVE", por exemplo, para todos os indices abertos, e aquele com sem conexão daria erro na transmissão.

Em ambas situações não consegui o resultado esperado pois:
Timer: os indices ficam sempre abertos com o mesmo IP do cliente
KEEP ALIVE: como o índice (velho) armazena o IP do cliente, a mensagem é encaminhada para o cliente com IP ativo.

Acredito que este tipo de situação seja um tanto quanto incomum pois não encontro tópicos relacionados ao assunto.

Este comportamento tem impactado no servidor pois a cada nova requisição de conexão é alocado um socket na memória do computador.

Isto me cheira que a tua REDE (GSM) está com problemas...como voce falou...o cliente nao está mandando a mensagem de desconexão na camada mais embaixo do PROTOCOLO.
Estas com qual operadora ? Ocorre nas outras ? O problema ocorre tambem com sockets simulados (fora da rede GSM) ?
Uma opção é forcar um close no socket, por parte do servidor...o pior se a mensagem nao chegar ao cliente...tem como parametrizar no teu cliente o TIME TO LIVE do socket ?
Na nossa pilha TCP/IP tivemos que adicionar este recurso...pq estava havendo muitas retransmissões de pacotes pq a rede nao os entrega na ponta...gerando contas altissimas...
xau
TCPIPCHIP

Ocorre com outras operadoras também. Não consigo simular a situação para debugar no servidor para tratar.

O cliente somente fica enviando os dados apartir do estabelecimento do link e o servidor somente atualiza a aplicação com estes dados.

Não acho que seja problema da rede GSM/GPRS e sim uma característica da rede/aplicação.
Seria como se um computador estivesse sendo arrancado da rede, retirando o cabo, por exemplo, como ele poderia enviar um close para o socket?

Acho que tenho de tratar isso no servidor mesmo. Mas o problema é que cheguei a fazer um teste enviando uma espécie de KEEP ALIVE para o IP mas como ele está ativo não dá erro na transmissão.
Coloquei um contador para cada índice do socket aberto com o mesmo IP e são vários.

Não sei se o windows gerencia isto, fechando o índice do socket, que fica na memória, depois de um tempo. Pelo que verifiquei, no windows ficam vários em TIME_WAIT.