The open-source game engine and graphics engine for multiplayer, cross-platform, real-time 3D action

I've asked a friend who's a skilled programmer knowledgeable in networking to look into Cafu to implement a better dedicated server and implement IPv6.

He'll be reading through for a while and I was wondering if everyone, especially Carsten, input what changes they feel are critical to improving the engine on the network end of things.

Right now Cafu doesn't have a true dedicated server, just a headless, the dedicated server would be a stripped down and enhanced Cafu child project rolling with the latest version.

The only things I've asked to be implemented are IPv6 and a simple key based user system which can be expanded upon on later.

I'll also try having another person look into this since he doesn't have a lot of time.

Hi HWGuy,

HWGuy wrote:

I've asked a friend who's a skilled programmer knowledgeable in networking to look into Cafu to implement a better dedicated server and implement IPv6.

The IPv6 part should be relatively easy to implement, and it should be possible to do it nicely isolated from everything else.
We even have a ticket with some additional info already:
http://trac.cafu.de/ticket/42

Quote:

He'll be reading through for a while and I was wondering if everyone, especially Carsten, input what changes they feel are critical to improving the engine on the network end of things.

Well, on the UDP layer, things are somewhat old (you can "see" the age in the style of the code), but otherwise there are no known problems with it. It's battle-tested and stable.

Personally, what I'd like to see in the mid or long term, is a replacement of our own reliable/unreliable packet layer with SCTP:
http://en.wikipedia.org/wiki/Stream_Con ... n_Protocol
http://www.sctp.de/sctp.html
This needs more research though, and generally is a large task.

Quote:

Right now Cafu doesn't have a true dedicated server, just a headless, the dedicated server would be a stripped down and enhanced Cafu child project rolling with the latest version.

Well, yes. I made a few half-hearted attempts to create a dedicated server in the past, but eventually (re-)focused on things that seemed more important every time.

It's probably not too difficult to strip down the existing "full" executable to a dedicated server (using the "null" renderer and sound system), but the question is how you would like to communicate with it.
You'd have to provide console input and output either from the local keyboard and to the local screen, and/or have it communicate via a game client.
For this too there is some existing old (and working!) code (check out the rcon console command), but from today's point of view I'd rather have the (dedicated) server listen on a separate port for control (console) commands, with connections preferably tunneled via SSH.

Quote:

The only things I've asked to be implemented are IPv6 and a simple key based user system which can be expanded upon on later.

What do you mean by "key based user system"?

_________________
Best regards,
Carsten

Carsten wrote:

What do you mean by "key based user system"?

A key based user system is an approach similar to how Teamspeak works.
When you create the server it generates a master key for administering remotely, while people who connect with their username have their own unique key generated by client and server.
Basically it opens up the door for any form of account system, from completely open free game with user tracking, to closed paid-for game where keys are centrally controlled.

So the server would keep a database of users, where is user has properties like username, passphrase (the "key"), game score, game assets / spells / etc. ?

Never thought about it (in the context of a Cafu game server), but it seems like an attractive idea.

_________________
Best regards,
Carsten

just to clear things how ts3 works:
- authenticating is done using public/private key, no passphrases and usernames are just for human readability
- rights can be granted ether directly someone who is/was online already (server knows the public key) or a one-time-keyword can be generated for future use which gives the rights who enters the keyword

Ya I knew that, but it's limited so I've been playing with password seeded keys, with anonymous/nologin being a randomly picked key... however... there's a vulnerability with that, if the client picks the cipher it has to send it to the server, if the server generates the key, it has to send it to the client... a vulnerability that's regularly exploited online with all sorts of things.