zige-p2pse Mailing List for ZIG Game Engine
Status: Beta
Brought to you by:
fcecin
You can subscribe to this list here.
2006 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
---|
From: <fc...@gm...> - 2006-03-22 20:46:48
|
Esquem=E1tico da API de baixo n=EDvel do P2PSE: https://saloon.inf.ufrgs.br/twiki/view/FreeMMG/P2PSELowLevelAPI Acho que neste esqueleto deve ter pelo menos 90% dos m=E9todos necess=E1rios... =C9 claro que isto =E9 s=F3 um dos poss=EDveis designs. Estou me baseando em algo parecido que tinha feito no FreeMMG (s=F3 que o FreeMMG era sobre TCP, o que descartava a necessidade da API de separar as "mensagens confi=E1veis" e os "blocos n=E3o-confi=E1veis", e da necessida= de da API de ter um m=E9todo para explicitamente despachar pacotes, que s=E3o duas preocupa=E7=F5es que voc=EAs v=E3o notar presentes nesta API - m=E9todos send_packet(), e m=E9todos receive_message() e send_message()) Fabio |
From: <fc...@gm...> - 2006-03-13 20:46:36
|
Oi, Primeiro, avisando que criei esta lista: zig...@li... para que a gente possa discutir o desenvolvimento da nossa biblioteca. Por enquanto s=F3 tem n=F3s tr=EAs (F=E1bio, Diego, Joana) e n=E3o tem nenhum estrangeiro aqui ent=E3o d=E1 pra escrever em portugu=EAs mesmo :-) ... Segundo, estava lendo o src/peer.cpp de voc=EAs, e achei esta parte: --//-- int peer_c::connect(address_c remote_peer_addr) { if (get_remote_peer(remote_peer_addr) !=3D NULL) { // TODO: manage multiple connections (vport) return -1; } --//-- S=F3 para avisar que, em princ=EDpio, m=FAltiplas conex=F5es entre duas m=E1quinas de jogadores n=E3o devem ser necess=E1rias, pois cada jogador pode estar participando de, no m=E1ximo, uma sess=E3o P2P de jogo (ao menos =E9 o que est=E1 planejado para o projeto). Isto =E9, ou o jogador est=E1 somente conectado ao servidor (jogando na "cidade") ou ent=E3o o jogador est=E1 conectado ao servidor E a um grupo de peers, com uma conex=E3o para cada um. Por=E9m, eu acho que o vport vai ser necess=E1rio no seguinte contexto: "v=E1rias" conex=F5es com o servidor. Ao menos teria uma conex=E3o com a "classe servidor" propriamente dita, e uma conex=E3o opcional com uma classe "manager" (tamb=E9m na m=E1quina servidora) que seria respons=E1vel por gerenciar a sess=E3o P2P do usu=E1rio (quando ele estiver jogando). Este "manager" iria, por exemplo, enviar mensagens para a classe "peer" na m=E1quina do cliente, informando quais os endere=E7os IP:PORTA dos outros peers, controlando para ver quais peers conseguiram conectar em quais outros, etc. A moral dessa separa=E7=E3o seria que a conex=E3o com o "manager" poderia falhar/cair, mas a outra conex=E3o, com a classe "servidor", continuaria de p=E9. Por=E9m, as duas seriam conex=F5es "l=F3gicas", em cima do mesmo socket UDP, e ambas apontariam para o mesmo IP:PORTA na m=E1quina servidora. Outra possibilidade de uso (talvez fa=E7a at=E9 mais sentido) =E9 usar uma conex=E3o para trafegar mensagens do "engine" (nossas mensagens, da implementa=E7=E3o do P2PSE) e outra conex=E3o para trafegar mensagens exclusivamente da aplica=E7=E3o (mensagens do jogo que roda em cima da biblioteca P2PSE). Isso evitaria aqueles "casos especiais" e "IDs m=E1gicos" que voc=EAs viram no station.h do zig. Mas isso tudo ainda precisa ser visto com calma. []s Fabio |