o_O Dedicated server ...

[Auswaschbar]

... is not yet finished, but will be in near future. For now I'm thinking of how it can be distributed:

1. As a shared library
pro:
- more flexible (direct function calls for setting options, no need for AutohostInterface etc.)
- can be integrated into lobby / autohost / ladder server / whetever
- less work for me
- option 2 could be emulated by writing an simple executable for parsing script etc.

2. As a stand-alone executable
pro:
- behaves more like spring.exe
conn:
- more work for me
- noobs asking: "ZOMG I double-clicked server.exe and nothing happenz!!!1"

PS.: the library would simply contain a class like "GameServer". Usage draft:

Code: Select all

GameServer* myDedicatedServer = new GameServer(myGameSetup, myPort);
while (myDedicatedServer.Running())
{   sleep(1);
}
delete myDedicatedServer;

Springlobby could use a code segment like this to run a ded. server.
Unfortunately I don't know how Java (AFLobby) and Pascal (TASClient) support shared libraries.

Feel free to post feedback here.

PS.: I would prefer Option 1

[imbaczek]

Why is a shared library different than an executable? You could make a simple shared library runner by putting initialization stuff in main().

I think that it doesn't matter as long as a dedicated server can run without a X display of any kind.

[AF]

imo a standalone program that took a script file like spring would be much much better.

[imbaczek]

dll/so is almost a standalone program, anyway.

[Auswaschbar]

Why is a shared library different than an executable? You could make a simple shared library runner by putting initialization stuff in main().

Thats the point. It isn't a trival task to parse a startscript.

[semi]

The dedicated server should be the only server.

When you host normally, what should happen is that both a dedicated server and your local client spring program get launched.

Then, when your local client program crashes to a LuaUI bug or whatever, the server keeps on going, and even keeps on going when you get bored to waiting for the game to end because you are the host, and you'll just join another game while it's still in progress.

[AF]

Setting up library APIs is not a trivial task either, and it cannot be ran standalone. The user would have to write their own program to make use of the library.

In the end its offloading work onto a sector of the spring community that has some of the longest to do lists spring has ever seen.

[semi]

AF: nothing prevents having the standalone exe version to actually be a small exe that loads and runs the shared library.

Best of both worlds.

[Auswaschbar]

Setting up library APIs is not a trivial task either, and it cannot be ran standalone. The user would have to write their own program to make use of the library.

The user would have to write their own program to make use of the executable. You still need some program to write the script (and distribute the script to the clients).

[Satirik]

Setting up library APIs is not a trivial task either, and it cannot be ran standalone. The user would have to write their own program to make use of the library.

The user would have to write their own program to make use of the executable. You still need some program to write the script (and distribute the script to the clients).

you should talk with Licho, dedicated host comes with autohost : springie

[Mr.Frumious]

The dedicated server should be the only server.

When you host normally, what should happen is that both a dedicated server and your local client spring program get launched.

Then, when your local client program crashes to a LuaUI bug or whatever, the server keeps on going, and even keeps on going when you get bored to waiting for the game to end because you are the host, and you'll just join another game while it's still in progress.

While that works nicely for other games, I imagine that a dedicated server will still need to track gamestate. That means having 2 complete sims running on your machine instead of one. Bad, bad solution.

[Auswaschbar]

While that works nicely for other games, I imagine that a dedicated server will still need to track gamestate.

It doesn't keep track of the gamestate, it just compares each players checksumm.

[Tobi]

Personally I think I'd go with an executable just like spring.exe that then takes a script just like spring.exe - with some refactoring I think it should be possible to share the same (GameSetup) code between server and client, so the same script can be passed to both.

Also executables are easier to test and debug. IOW, if you write a library, you'll probably also want to write an executable anyway to test/debug all the library functions. Then you can aswell make it a useful executable IMHO

Added advantage is that if the server is a separate executable it doesn't need threading -> less chance for race conditions etc.

Of course it would be nice if internally the main program is just a few lines of very high level code that calls the underlying 'library'. That way it shouldn't be too hard to turn it into / add a library later, if someone feels like doing that.

Wrt the autohost interface, with a simple localhost TCP connection and proxy classes (maybe even in different languages if people contribute) I think that can be made very powerful. But maybe I'm looking a bit too far in the future

(All this is assuming we do not want to make the dedicated server a deamon that should be able to run all by itself for a long time. IOW, we'll just start it on game start and quit on game end, and some other supervisor process (Springie) could play deamon )

EDIT: I'm actually looking at uncrappyfying CGameSetup now because I still need to add player renumbering.

[ouno]

First of all, hello everbody, this is my first post here
And thanks to everyone working on Spring project.

As others, I think that a dedicated server version of Spring which doesn't need 3D hardware would be very nice.

IMO the shared library solution would be a good start.
Ideally, the GameServer class would provide:
- some usefull realtime in-game information (client status, ping, proc. usages...)
- a way to declare a callback for in-game chat messages parsing
- a way to send chat messages and server commands

That way, in a first time a small program could be written reusing the startscript parsing code of the original Spring executable. This would provide us the "simple" dedicated server.

Then, the library could be used by a AutoHost Daemon, which could then access both Battle Chat and in-game chat and data easily. This would allow:
- AutoHost Daemon commands such as "callvote_kick, callvote_forcestart, callvote_forceend ..." to be called from both Battle Chat and in-game Chat
- client information such as pings and processor usages to be used to trigger optional automatic actions (callvote_pause or callvote_kick when a player has ping > 10s or proc. usage > 60% for example)
- in-game chat to be redirected in Battle Chat and vice versa

A dedicated localhost TCP connection + proxy classes could certainly do the job too, but isn't it "too much" for this usage ?

[Tobi]

The IMHO huge advantage of a separate process, optionally with proxy classes over a local conn, is that you delegate all synchronization issues to the OS (a local conn is a nicely abstracted synchronized message queue after all), and that the process boundary protects the application running the server from memory corruption and other nasty bugs in the server (which shouldn't happen in the first place of course, but when they happen it's nice if the impact isn't too big, especially since the server is a server .. ie. security issue).

A shared library may seem nice at first, but remember that if you really want to publicize classes, you'll need to do proxy classes too unless you want to
1) force everyone to use the same compiler (remember C++ ABI is not standard and even differs between GCC/MSVC versions)
2) do compiler dependent stuff like __attribute__((alias("aliasname"))) (not sure about exact syntax) to make the class visible on the other compiler anyway. This probably won't work because of vtable issues and other ABI differences besides different name mangling. Besides that it will be a lot of fugly hacking that quickly breaks down.

This all comes down to the fact that you can only export 'extern "C"' functions, and then optionally write a proxy class around them that 'turns the extern "C" functions into a class again'.

So basically you need a proxy class anyway, unless you really want to sacrifice interoperability by requiring a particular C++ ABI.

Since we also already got the local conn (though UDP now, the "AutoHostInterface"), I think a separate process would be the way to go.

But then again, I'll leave the decision to Auswaschbar, since he's the one doing the hard work

(I think KDE also uses proxy classes over local network conns to implement transparent (to the programmer) interprocess communication, they might have a tool to generate those proxies? Definitely the sharedlib proxy, ie. C++ -> C -> C++, should be pretty easy to generate automatically.)

[bibim]

So, finally, which solution has been chosen ?

I suppose the dedicated server feature won't be included in Spring 0.76 ? maybe the version after ?

I'm thinking about making an advanced AutoHost daemon in Perl for dedicated servers (unitsync library calls would be performed through a Perl extension module). The goal is to be able to run dedicated Spring hosts on Linux boxes without graphic card...

[Licho]

I (being springie autohost developer) don't care.
If its easier for you to implement simple dll go for it. If not I think the most flexible solution would be exe and some communication interface (could be process input/output, named pipe or some network loopback as implemented in spring right now).

Modifying springie for either option should be relatively easy and straightforward..

But exacutable witll make Springie be more easilly portable for mono/linux, unlike dll.

[Auswaschbar]

I will make a standalone executable (which only contains few and simple code).

If someone is interested:
There is a development snapshot in svn (tools/DedicatedServer). Actually you can't do anything else than joining, chatting, mapdrawing and leaving, but it compiles and works.

[bibim]

Yeah I saw it. I compiled it on my Linux box and launched it without problem but I didn't test anything else.