Difference between revisions of "GenServ"

From Ghoulwiki
Jump to: navigation, search
 
 
(10 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 ==
 +
 +
* 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 ==
 +
 +
<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

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