> Hum, como vai ter pontuacao, provavelmente tera nicknames fixos ou vai
> usar o ID do usuario... Que tal uma regra para medir inatividade depois de
> um determinado periodo... talvez usando um ou algo assim para reativar a
> contagem?

> Tambem penso que se vai contar pontos por segundo, o usuario poderia ficar
> varias horas conectado mas sem interagir... essa contagem em vez de
> segundos ser por minutos como foi citado, a meu ver e bem mais
> interessante... pois voce estaria usando lado cliente para ajudar um pouco
> no processamento ao acumular a pontuacao a cada minuto e so entao enviar ao
> servidor...

> Em 22 de agosto de 2012 01:12, Bruno Carvalho <bment...@gmail.com>escreveu:

> Sobre o lance dos segundos, a forma como eu resolveria inicialmente seria
>> calcular os segundos quando ele saísse apenas. Ou seja, a pontuação por
>> tempo ocorre: ao sair e a cada minuto. Vc registra a hora de entrada do
>> indivíduo e uma vez por minuto faz broadcast da pontuação nova. Quando ele
>> desconectar, voce pega a hora/min/seg da saida e diminui da hora/min/seg da
>> entrada e soma os pontos no banco.

>> Assim, a pontuação por tempo é atualizada no banco de tempos em tempos,
>> preferencialmente quando o usuário sai.

>> Tudo bem que seu modelo favorece "bots" e não sei se é isso que quer.
>> Quem é antigo aqui e acessou a Efnet (IRC) sabe que um eggdrop bot ficava
>> lá enquanto vc nao tava pra segurar o nick. Conexão desperdiçada sem
>> ninguém de fato interagindo... ;)

>> Abs

>> Em 21 de agosto de 2012 21:39, @thwess <1thw...@gmail.com> escreveu:

>> Eu acredito que seja assim como o Diego disse, vc mantém uma
>>> manutenção periódica e faz broadcasts somente para eventos não regulares.

>>> Em relação ao disconnect, eu acredito que o socket consegue capturar o
>>> disconnect imediatamente, e já logo lançar o evento para o usuário.
>>> A questão mais preocupante é o disconnect por queda de conexão, que pode
>>> gerar aquele delay chato, e esse tempo ou vc corrige ou terá q dar mérito
>>> ao usuário q conseguiu manter o delay, pq c vc não conseguiu pegar o tempo
>>> exato que ele desconectou, então significa que os pontos até então
>>> computados, são dele e não devem ser removidos erroneamente.

>>> Sobre o bd, eu aposto na mesma ficha da ideia de manutenção. Vc mantém
>>> toda pontuação dos usuários armazenada em uma collection no servidor e
>>> repassa para o bd em eventos regulares para diminuir o gargalo.

>>> Em terça-feira, 21 de agosto de 2012 21h10min09s UTC-3, Filipe escreveu:

>>>> Evento de auto manutenção... hmmm interessante.

>>>> O problema será que, se eu fizer o cálculo por tempo na desconexão do
>>>> chat, ao ter um evento externo que fará a manutenção dos pontos
>>>> correntes, eles não vão casar com o que está no lado do cliente, pois
>>>> nestes pontos correntes ainda não terá sido somado o tempo de conexão
>>>> (pelo disconnect).

>>>> Faz sentido?

>>>> On Aug 21, 9:02 pm, diego nunes <dnu...@gmail.com> wrote:
>>>> >     Agora fez sentido :)

>>>> >    Obviamente você não vai enviar o evento de "passei um segundo no
>>>> chat"
>>>> > para os usuários, somente os "joins" e os "parts". O resto é
>>>> calculado no
>>>> > client.
>>>> >     Como você estará usando socket, você já terá um evento de "saiu
>>>> do
>>>> > chat" (dependendo do método de conexão, há um delay relativamente
>>>> grande
>>>> > até a detecção de conexão fechada, então você vai ter que subtrair
>>>> alguns
>>>> > segundos ou exigir determinados tipos de conexão).
>>>> >     Assim somente os eventos de mensagem e de "like" vão ter
>>>> broadcast (com
>>>> > a pontuação corrente e o timestamp, para atualizar o ponto de
>>>> sincronia dos
>>>> > clients, como forma de auto-manutenção), e somente para os usuários
>>>> > "visíveis" (a sala atual, talvez?).
>>>> >     Um bom serviço de socket suporta milhões de mensagens por
>>>> segundo. O
>>>> > limite fica na conexão do client, não no socket. Considerando isso,
>>>> para
>>>> > melhorar mais a performance, você pode fazer esses broadcasts
>>>> > periodicamente e não assim que os eventos ocorrem, ou enviar o
>>>> broadcast
>>>> > num mesmo pacote que vai uma nova mensagem recebida no chat. Assim
>>>> você
>>>> > teria as trocas de pacotes reduzidas a um mínimo enquanto mantém o
>>>> ritmo de
>>>> > atualização super constante (dá pra manter os updates com menos de um
>>>> > segundo de atraso)*.*
>>>> > On Aug 21, 2012 8:52 PM, "Filipe" <fili...@gmail.com> wrote:

>>>> > > Diego, obrigado meu caro.

>>>> > > É noSQL (MongoDB).

>>>> > > Não é necessário o histórico, mas preciso que toda atualização na
>>>> > > pontuação do usuário (seja ela causada pelo próprio usuário, por um
>>>> > > usuário terceiro ou pelo segundo que se passou), precisa refletir
>>>> no
>>>> > > lado do cliente.

>>>> > > Eu criei uma forma, mas ela pode explodir em pedaços o banco de
>>>> dados:
>>>> > > a cada evento, eu faço um increment na pontuação atual do usuário
>>>> em
>>>> > > questão (com uma atomic operation), pego então o valor atualizado
>>>> > > final e envio de volta ao usuário em questão.

>>>> > > Se estes eventos de atualização de pontos forem gerados somente nas
>>>> > > trocas de mensagens, ok (pois eu já estou salvando as mensagens no
>>>> > > banco). Mas e a atualização a cada segundo? Se eu tiver 300 pessoas
>>>> > > conectadas, são 300 interações com o banco de dados.

>>>> > > Ele vai explodir!

>>>> > > On Aug 21, 8:34 pm, diego nunes <dnu...@gmail.com> wrote:
>>>> > > >     Você precisa do histórico de pontuação? Se não precisa, vai
>>>> ter só
>>>> > > > contador de pontos, provavelmente na tabela de usuários (ou no
>>>> registro
>>>> > > do
>>>> > > > usuário, se for um noSQL).
>>>> > > >     Se precisar, sugiro uma tabela de registro da pontuação e um
>>>> "cache"
>>>> > > do
>>>> > > > somatório para ser consultado de forma rápida. A atualização
>>>> desse cache
>>>> > > > seria em tempo real e haveria uma rotina de auto-manutenção para
>>>> > > atualizar
>>>> > > > periodicamente o valor. Há muita coisa envolvida nesse tipo de
>>>> técnica e
>>>> > > > não vou entrar em detalhes sem saber se é necessário porque a
>>>> explicação
>>>> > > > seria longa e eu estou no celular :)

>>>> > > >     Dê mais detalhes aí. A priori parece simples, na verdade.
>>>> > > > On Aug 21, 2012 7:24 PM, "Filipe" <fili...@gmail.com> wrote:

>>>> > > > > Pessoal, o cenário é o seguinte: Express, Socket.io e MongoDB.

>>>> > > > > Construí um sistema de chat onde o usuário é remunerado com
>>>> pontos da
>>>> > > > > seguinte forma:
>>>> > > > >  - Ganha 1 ponto a cada segundo que ele passa conectado
>>>> > > > >  - Ganha 1 ponto a cada mensagem que ele envia ao chat
>>>> > > > >  - Ganha 1 ponto, caso um outro usuário "curta" a mensagem
>>>> dele.

>>>> > > > > Seja qual for a forma como ele ganha este ponto, o client side
>>>> do
>>>> > > > > usuário precisa ter a resposta em tempo-real dos atuais pontos.

>>>> > > > > Como vocês resolveriam esta charada sem abarrotar o banco de
>>>> dados? :)

>>>> > > > > (nao procuro código, apenas a lógica ou conceito)

> --
> Wemerson Guimarães
> Rio Verde - Go - Brasil