Complete.Org: Mailing Lists: Archives: freeciv-dev: October 2002:
[Freeciv-Dev] Re: connect dialog ver 3 (PR#1911)
Home

[Freeciv-Dev] Re: connect dialog ver 3 (PR#1911)

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Freeciv-Dev <freeciv-dev@xxxxxxxxxxx>
Subject: [Freeciv-Dev] Re: connect dialog ver 3 (PR#1911)
From: Vasco Alexandre Da Silva Costa <vasc@xxxxxxxxxxxxxx>
Date: Tue, 22 Oct 2002 05:34:23 +0100 (WET DST)

On Mon, 21 Oct 2002, Christian Knoke wrote:

> civclient should be able to control civserver. There is no need to mix up
> the concepts. It doesn't even matter whether civclient starts civserver
> or civserver is started independantly. The client automatically connects
> to the server, can set up all options via a gui dialog, can allow or
> disallow other players to connect to the server, can start the game.

This is also my idea on the matter. I see no sensible reason against why
you cannot have a GUI in the client to do the same kinds of things you
can do now in the client chatline/commandline.

This includes a GUI for setting variables and buttons or menus for running
commands like '/start', '/endgame' and so on.

> The civserver shouldn't be killed if civclient crashes. That's why it may
> be good to start them independently.

Yes. That is why I don't want the client to fork() the server and control
stdin/stdout using pipes. If the client dies how will you regain control
of the server? I like things separate and squeaky clean.

Also pipes are not easily portable to other platforms. Unlike
BSD sockets UNIX pipes are not ubiquitous. Not to mention fork() ...

We have already a good controlling method via the client... Why add
another one?

What is the difficulty of a user running a separate server? Heck it is
just an extra click on your "start menu" to spawn the server...
You don't even need to directly interact with the bloody thing.
If you want to kill the server just click the X-Term window close
button...

You can do a GUI to control the server regardless of this nonsense.

> Several civclients should be able to control the civserver simultanously.
> But for a first step it may be sufficient if the first civclient takes
> control.
>
> There is a security impact. Right now, civserver should not be controlled
> by a remote client. This may change, if we have a way for secure
> authentication. Right now, civserver should check whether the civclient
> is local. Under Unix, AFAIK this is possible by checking whether it connects
> via loopback interface. (I don't know how this works with windows, though).
> First local civclient gets commandlevel hack.

> The above implies that control takes place via TCP/IP, not pipes.

Yes IMO we need some way to grant cmdlevel hack to players connecting by
TCP/IP. A more flexible method than the one you propose would be:

When the server starts up it generates this huge random number or
password i.e. a key. It stores it in a key file.
It will only grant access to someone who connects with that key.

Since only the person running the server should have file acess to the key
file things should be safe.

Of course someone could still intercept this key in flight... But you
don't really want to use public key encription in a game do you? You do?
Erm... well if you do... we can add that too. :)

---
Vasco Alexandre da Silva Costa @ Instituto Superior Tecnico, Lisboa



[Prev in Thread] Current Thread [Next in Thread]