Especificar protocolo de sinalização do jogo (versão preliminar v0.1)

Com base no SIP, visto em #4 e #5, e outros protocolos, definir e especificar o protocolo a ser usado no jogo. Esta não precisa ser a versão final do protocolo, que pode ter revisões ao longo do projeto, portanto será aqui denominada versão preliminar v0.1.

Como requisitos funcionais:

RF0: Implementar o modelo de requisição-resposta para atender ao modelo Web.
RF1: Ser agnóstico em relação aos protocolos inferiores (Aplicação/Apresentação/Sessão e Transporte) no que se refere a garantia de entrega. Portanto, para cada requisição deve haver uma resposta.
RF2: Prever respostas positivas e negativas para as requisições, permitindo o jogador/usuário decidir se quer atender as requisições de outros jogadores para participar, por exemplo, de sessões de mídia.
RF3: Prever a organização dos jogadores em salas ou namespaces para uso concorrente de um mesmo serviço com ambientes isolados entre si.
RF4: Prever que cada jogador tenha um identificador único, o qual pode ser um valor aleatório (hash criado dinamicamente, por exemplo) ou fixado pelo próprio usuário, como por exemplo uma URI conhecida. Para este último, será preciso, adicionalmente, implementar esquema interno ou externo de autenticação (Oauth, por exemplo).
RF5: Prever a criação e destruição de salas ou namespaces. Opcionalmente, pode haver administração das salas para os criadores, e para este caso é preciso definir pelo menos dois níveis de permissão por sala (criador, outros). Além disso, é opcional a persistência de salas no serviço (estado, listas de permissão ou bloqueio de jogadores etc.).
RF6: Com a organização de salas ou namespaces, prever sistema de presença de usuários para apresentação aos demais, de forma que seja possível o convite posterior.
RF7: Prever convites diretos entre jogadores, na modalidade PVP (player-versus-player), de forma análoga ao unicast.
RF8: Prever convites entre um jogador e todos os demais de uma determinada sala ou namespace, de forma análoga ao multicast (seleção de n jogadores dentro todos do serviço). Ou seja, atender a comunicação entre 2 ou mais jogadores.
RF9: Prever o encapsulamento de um protocolo de negociação e descrição de mídia para que o navegador consiga negociar caminhos (Rede, Transporte), mídias e codecs (Aplicação).

Como requisitos não funcionais:

RNF1: Estar de acordo com os fundamentos da disciplina de Projeto de Protocolos.
RNF2: Ser um protocolo baseado em texto e legível (para humanos).

ederson-torresini / smu20202

Especificar protocolo de sinalização do jogo (versão preliminar v0.1) #6