Difference between revisions of "GenServ"
From Ghoulwiki
Ghoulsblade (talk | contribs) |
Ghoulsblade (talk | contribs) |
||
| (9 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
| + | |||
| + | == genserv == | ||
| + | |||
* https://merlin.leenox.de/genserv | * https://merlin.leenox.de/genserv | ||
| + | * git clone gitosis@zwischenwelt.org:genserv.git (currently only private git) | ||
| + | |||
| + | == udpserv == | ||
| + | |||
| + | * genserv itself is currently tcp based and multithreading enabled (heavy c++ boost use) | ||
| + | * udpserv is a variant/spinoff using a similar protocol but for udp, implementing "reliable" udp with resend-interval until acknowledge is received | ||
| + | * similar to irc with "chatrooms" that can be joined and broadcast messages to all within, but more for realtime / game network data communication | ||
| + | |||
| + | <pre> | ||
| + | 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 | ||
| + | </pre> | ||
== comparison with irc == | == comparison with irc == | ||
| Line 10: | Line 45: | ||
** minimized delay : made realtime game data communication | ** 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 | ** channel meta / mailboxes : larger messages (avatar pictures, maps) can be stored in server-side database and requested by id | ||
| + | |||
| + | |||
| + | |||
| + | == reliable udp == | ||
| + | |||
| + | <pre><nowiki> | ||
| + | <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 | ||
| + | </nowiki></pre> | ||
| + | |||
| + | == 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. | ||
| + | <pre><nowiki> | ||
| + | <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 | ||
| + | </nowiki></pre> | ||
Latest revision as of 20:02, 4 September 2011
genserv
- https://merlin.leenox.de/genserv
- git clone gitosis@zwischenwelt.org:genserv.git (currently only private git)
udpserv
- genserv itself is currently tcp based and multithreading enabled (heavy c++ boost use)
- udpserv is a variant/spinoff using a similar protocol but for udp, implementing "reliable" udp with resend-interval until acknowledge is received
- similar to irc with "chatrooms" that can be joined and broadcast messages to all within, but more for realtime / game network data communication
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
