Difference between revisions of "GenServ"
From Ghoulwiki
Ghoulsblade (talk | contribs) |
Ghoulsblade (talk | contribs) |
||
Line 26: | Line 26: | ||
[uint8:kMsgType_Welcome] [uint32:ownid] // s->c server sends this as reply to kMsgType_Welcome | [uint8:kMsgType_Welcome] [uint32:ownid] // s->c server sends this as reply to kMsgType_Welcome | ||
[uint8:kMsgType_Quit] // c->s client sends this before termination, for faster timeout ? | [uint8:kMsgType_Quit] // c->s client sends this before termination, for faster timeout ? | ||
− | [uint8:kMsgType_Ping] | + | [uint8:kMsgType_Ping] // s->c c->s client replies with kMsgType_Ping |
</pre> | </pre> | ||
Revision as of 11:06, 15 August 2011
- https://merlin.leenox.de/genserv
- git clone gitosis@zwischenwelt.org:genserv.git (currently only private git)
udpserv
typedef enum { kMsgType_Undefined = 0, kMsgType_NormalUDP = 10, kMsgType_ReliableUDP, kMsgType_Ack, kMsgType_JoinRoom, kMsgType_LeaveRoom, kMsgType_Hello, kMsgType_Welcome, kMsgType_Quit, kMsgType_Ping, } eMsgType; [uint8:kMsgType_NormalUDP] [uint32:to]...data... // c->s s->c [uint8:kMsgType_ReliableUDP] [uint32:ackid][uint32:to][uint32:interval]...data... // c->s s->c will be resent until acknowledged, might arrive multiple times [uint8:kMsgType_Ack] [uint32:ackid]...data... // c->s s->c data optional, e.g. roomid for join [uint8:kMsgType_JoinRoom] [uint32:ackid][str:roomname] // c->s ack with data=roomid [uint8:kMsgType_LeaveRoom] [uint32:ackid][uint32:roomid] // c->s [uint8:kMsgType_Hello] // c->s client sends this, answered by kMsgType_Welcome [uint8:kMsgType_Welcome] [uint32:ownid] // s->c server sends this as reply to kMsgType_Welcome [uint8:kMsgType_Quit] // c->s client sends this before termination, for faster timeout ? [uint8:kMsgType_Ping] // s->c c->s client replies with kMsgType_Ping
comparison with irc
- similarities :
- channels
- pms
- differences
- minimized delay : made realtime game data communication
- channel meta / mailboxes : larger messages (avatar pictures, maps) can be stored in server-side database and requested by id
reliable udp
<ghoulsblade> für ne reine udp brauchen wir noch confirm nachrichten <ghoulsblade> und config für resend-interval und timeout <ghoulsblade> evtl regelmässige roundtrip-time messung für dynamischen resend interval, damits so schnell wie möglich resendet wird bei störung aber nicht immer doppelt geschickt wird wenns keine störung gibt <ghoulsblade> vll sogar 2 typen von reliable <ghoulsblade> fast auf kosten von bandbreite und slow mit mehr längerem interval
notes
- website doc : optimized for game-jammers : api provided by lib first, technical internas later, not interesting, e.g. id resolve capsuled ?
- udp : ordering-group id ? ordered but unreliable, option to automatically get latest successfully transmitted in group.
<ghoulsblade> z.b. wenn client jedes frame die eigene position broadcastet, api packt automatisch ne nummer dazu <ghoulsblade> ne aufsteigende nummer, mit jedem broadcats um 1 erhöht <ghoulsblade> und man kann dann auf empfängerseite immer das letzte abrufen. wenn eins verspätet ankommt und man schon ne neuere nummer hat, wirds verworfen