CLIENTE/SERVIDOR NA LAN
Bom pessoal, estou criando um programa para uma lanhouse e tenho uma duvida:
Em uma LAN com 14 computadores + 1 servidor, eu poderia colocar 14 programas clientes sempre conectados ao servidor sem que aconteça perda de desempenho na rede? Sendo que na maioria no tempo o pessoal esta jogando counter-strike na rede usando os 14 micros.
é uma pergunta boba mas eu não entendo quase nada de rede.
Abraços
LEOx
Em uma LAN com 14 computadores + 1 servidor, eu poderia colocar 14 programas clientes sempre conectados ao servidor sem que aconteça perda de desempenho na rede? Sendo que na maioria no tempo o pessoal esta jogando counter-strike na rede usando os 14 micros.
é uma pergunta boba mas eu não entendo quase nada de rede.
Abraços
LEOx
Leox:
AÃ depende...
Vai da forma como o jogo foi montado.
Em primeira análise, o aplicativo que está no servidor é descarregado totalmente na máquina do usuário. A partir daÃ, é o próprio cliente que se incumbe de rodar o programa, não representando "peso" para o servidor.
Mas...
Por exemplo: em jogos como o da Lara Croft, as cenas de transição de fases são carregadas a partir do CD, de modo que se estiver jogando em rede, esse drive vai ser requisitado de vez em quando (e aquele filminho pesadÃssimo vai passar pela rede). Tudo bem que esse não é um bom exemplo, já que não é multiusuário (que eu me lembre), ou pelo menos não foi bolado para ser...
Sendo o Counter Strike um jogo pensado desde o começo para ser multiusuário, acredito que tais comunicações com o servidor sejam as mais compactas e simples possÃveis. Seu servidor deve aguentar sossegado.
AÃ depende...
Vai da forma como o jogo foi montado.
Em primeira análise, o aplicativo que está no servidor é descarregado totalmente na máquina do usuário. A partir daÃ, é o próprio cliente que se incumbe de rodar o programa, não representando "peso" para o servidor.
Mas...
Por exemplo: em jogos como o da Lara Croft, as cenas de transição de fases são carregadas a partir do CD, de modo que se estiver jogando em rede, esse drive vai ser requisitado de vez em quando (e aquele filminho pesadÃssimo vai passar pela rede). Tudo bem que esse não é um bom exemplo, já que não é multiusuário (que eu me lembre), ou pelo menos não foi bolado para ser...
Sendo o Counter Strike um jogo pensado desde o começo para ser multiusuário, acredito que tais comunicações com o servidor sejam as mais compactas e simples possÃveis. Seu servidor deve aguentar sossegado.
Certo.
é claro que a idéia de colocar um programa tipo agenda no servidor é uma péssima idéia. Não coloque timer nem loops na rede, essa é a regra. Com o Winsock você pode gerenciar o tempo de uso de maneira muito mais eficaz. Veja: ao carregar o aplicativo no cliente, ele mesmo guardaria o horário, avisaria pro servidor que horário é esse (assim, você poderia montar no servidor uma tabela de contagem regressiva para as máquinas, mas sem consultar o tempo restante em cada uma - usaria apenas o horário inicial fornecido pelo cliente) e colocaria o reloginho de contagem regressiva na tela do cliente. Você não precisa comunicar o tempo que resta pro servidor. Quando esse tempo acabar, o próprio servidor tomaria as providências necessárias. Dessa forma, o reloginho do cliente só serviria para informá-lo do tempo restante, tirando o peso de ser um "informante" e evitando tráfego de rede.
Fuja do timer.
é claro que a idéia de colocar um programa tipo agenda no servidor é uma péssima idéia. Não coloque timer nem loops na rede, essa é a regra. Com o Winsock você pode gerenciar o tempo de uso de maneira muito mais eficaz. Veja: ao carregar o aplicativo no cliente, ele mesmo guardaria o horário, avisaria pro servidor que horário é esse (assim, você poderia montar no servidor uma tabela de contagem regressiva para as máquinas, mas sem consultar o tempo restante em cada uma - usaria apenas o horário inicial fornecido pelo cliente) e colocaria o reloginho de contagem regressiva na tela do cliente. Você não precisa comunicar o tempo que resta pro servidor. Quando esse tempo acabar, o próprio servidor tomaria as providências necessárias. Dessa forma, o reloginho do cliente só serviria para informá-lo do tempo restante, tirando o peso de ser um "informante" e evitando tráfego de rede.
Fuja do timer.
Coloquei Winsock, mas até um .txt no servidor daria conta. Se você não precisa desse objeto no seu aplicativo, trabalhe com o .txt que vai dar certo também.
Resumo:
Cliente abriu o aplicativo
- envia mensagem para servidor armazenar ip da máquina e horário
- abre reloginho no canto da tela, e dispara contagem regressiva
- um timer no servidor monitora o tempo restante (se Time = horário gravado + tempo contratado então finaliza)
Se o cliente quiser continuar utilizando a máquina, basta editar o arquivo .txt, atualizando o horário daquela máquina.
Resumo:
Cliente abriu o aplicativo
- envia mensagem para servidor armazenar ip da máquina e horário
- abre reloginho no canto da tela, e dispara contagem regressiva
- um timer no servidor monitora o tempo restante (se Time = horário gravado + tempo contratado então finaliza)
Se o cliente quiser continuar utilizando a máquina, basta editar o arquivo .txt, atualizando o horário daquela máquina.
Outro esquema:
Cliente abriu o aplicativo
- envia mensagem para servidor armazenar ip da máquina e horário, e guarda o horário para seu controle também
- abre reloginho no canto da tela, e dispara contagem regressiva
- um timer no cliente monitora o tempo restante (se Time = horário gravado + tempo contratado então finaliza).
Como a contagem regressiva no servidor e no cliente é disparada ao mesmo tempo, em ambos os esquemas não é necessária a comunicação entre servidor e cliente (com exceção do inÃcio de operação). A opção por um ou outro esquema dependerá da configuração das máquinas (se você tiver 14 boas máquinas, então deixe para elas monitorarem o tempo, senão, jogue a tarefa para o servidor)
Cliente abriu o aplicativo
- envia mensagem para servidor armazenar ip da máquina e horário, e guarda o horário para seu controle também
- abre reloginho no canto da tela, e dispara contagem regressiva
- um timer no cliente monitora o tempo restante (se Time = horário gravado + tempo contratado então finaliza).
Como a contagem regressiva no servidor e no cliente é disparada ao mesmo tempo, em ambos os esquemas não é necessária a comunicação entre servidor e cliente (com exceção do inÃcio de operação). A opção por um ou outro esquema dependerá da configuração das máquinas (se você tiver 14 boas máquinas, então deixe para elas monitorarem o tempo, senão, jogue a tarefa para o servidor)
Puts! Nem tinha visto sua penúltima postagem!
Mas o Winsock trabalha com eventos... Se o cliente travar, não tem mais eventos pra comunicar! Por exemplo: se você montar uma tabela de IPs de máquinas conectadas, usando Winsock no Form_Activate , e uma delas travar ou alguém puxar o fio da tomada, o IP dela continuará aparecendo na lista!
Sinceramente: se a máquina travar, o cara vai levantar p... da vida, e vai exigir NA HORA que você o reconecte. Dá até pra montar uma rotina que desconte o tempo contratado do que foi utilizado antes do travamento (afinal, se travou, o tempo inicial ainda estará registrado) mas, convenhamos, se travou, nada mais justo que o cara receba um crédito novo, né?
A comunicação com Winsock, para os casos que você citou, não depende do Timer (ainda bem). Se o usuário quer ajuda, ele aperta um botão, que envia a mensagem via Winsock, ou, no caso de arquivo .txt, a máquina cliente edita o .txt no servidor e, lá, tem um timer que checa o txt de vez em quando pra ver se tem mensagem nova. Não põe timer na rede, Leox!
Agora, no caso de travamento do cliente... não se preocupe, que existe uma forma de comunicação muuuuito mais eficiente e rápida
Mas o Winsock trabalha com eventos... Se o cliente travar, não tem mais eventos pra comunicar! Por exemplo: se você montar uma tabela de IPs de máquinas conectadas, usando Winsock no Form_Activate , e uma delas travar ou alguém puxar o fio da tomada, o IP dela continuará aparecendo na lista!
Sinceramente: se a máquina travar, o cara vai levantar p... da vida, e vai exigir NA HORA que você o reconecte. Dá até pra montar uma rotina que desconte o tempo contratado do que foi utilizado antes do travamento (afinal, se travou, o tempo inicial ainda estará registrado) mas, convenhamos, se travou, nada mais justo que o cara receba um crédito novo, né?
A comunicação com Winsock, para os casos que você citou, não depende do Timer (ainda bem). Se o usuário quer ajuda, ele aperta um botão, que envia a mensagem via Winsock, ou, no caso de arquivo .txt, a máquina cliente edita o .txt no servidor e, lá, tem um timer que checa o txt de vez em quando pra ver se tem mensagem nova. Não põe timer na rede, Leox!
Agora, no caso de travamento do cliente... não se preocupe, que existe uma forma de comunicação muuuuito mais eficiente e rápida
Tudo bem. Não pensei no caso do SERVIDOR enviar mensagens pro cliente a todo momento pra ver se os cliente ainda estão conectados... é fria[S26] Confie nos usuários. Eles, se a máquina travar, vão dar um winSOCK em você
Tópico encerrado , respostas não são mais permitidas