[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-commits
Subject:    kdenonbeta/libkdegames
From:       CVS by andreas <kde-cvs () kde ! org>
Date:       2001-04-11 21:42:05
[Download RAW message or body]


kdenonbeta/libkdegames kgamecommunicationserver.cpp,NONE,1.1 \
kgamecommunicationserver.h,NONE,1.1 Makefile.am,1.10,1.11 TODO,1.24,1.25 \
kgame.cpp,1.54,1.55 kgame.h,1.44,1.45 kgamechat.cpp,1.15,1.16 \
kgameclient.cpp,1.16,1.17 kgameclient.h,1.6,1.7 kgamedialog.cpp,1.15,1.16 \
kgameio.cpp,1.27,1.28 kgameio.h,1.18,1.19 kgamemessage.cpp,1.3,1.4 \
kgamemessage.h,1.7,1.8 kgamenetwork.cpp,1.36,1.37 kgamenetwork.h,1.24,1.25 \
kgameprocess.cpp,1.10,1.11 kgameprocess.h,1.8,1.9 kplayer.cpp,1.46,1.47 \
                kplayerdata.cpp,1.23,1.24 kplayerdata.h,1.28,1.29
Author: andreas
Wed Apr 11 21:42:05 UTC 2001
In directory cvs.kde.org:/var/tmp/cvs-serv474

Modified Files:
	Makefile.am TODO kgame.cpp kgame.h kgamechat.cpp 
	kgameclient.cpp kgameclient.h kgamedialog.cpp kgameio.cpp 
	kgameio.h kgamemessage.cpp kgamemessage.h kgamenetwork.cpp 
	kgamenetwork.h kgameprocess.cpp kgameprocess.h kplayer.cpp 
	kplayerdata.cpp kplayerdata.h 
Added Files:
	kgamecommunicationserver.cpp kgamecommunicationserver.h 
Log Message:
Major update.
This is a design change:
We use now e real client-master architecture.
All clients send their messages to the KGameCommunicationServer which does
nothing but forwarding it to *all* client (even the one that sent the message).
This means that we have to care about only one client list (and we have some
performance losses :-( ). All clients have to store the location of the
KGameCommunicationServer and connecto to that one. That is what the
KGameClient*s are for. You create e.g. a KGameClientLocal for local
communication or a KGameClientSocket for network communication. Then you call
KGameClient::sendMessage() to send the message to the master
(KGameCommunicationServer). You can receive messages by connecting to
KGameClient::signalReceiveMessage(). 

This introduces a lot of bugs as it differs extremely from the design used
before. Now a program that sends a message must not send it locally (e.g.
sendMessage("Player 1 has won") and paintMessage("Player 1 has won") ) but just
send it to the network and will receive it from there (e.g. sendMessage("player
1 has won") and in receiveMessage: paintMessage(receiveString) ).

As the KGameClients are redisigned in this turn, too (KGameClientSocket and
KGameClientProcess are now different classes, both inherit from
KGameClientQueue ; KGameClientLocal is just a forwarding class) the computer
(process) player is broken now. KGameProcess is kind of fixed (at least on the
paper ;-) I have not tried it yet) but KGameProcessIO::writeBuffers() is a TODO

Another update in the message format: magic cookie + size of the message are now
*always* in the message. KGameMessages::dropExternalHeader is now obsolete.

kdenonbeta/kgame is working more or less with the current libkdegames. Although
there are some problems with not updated strings - probably because of the
mentioned change in the usage of sendMessage.

Some additional comments to KGameCommunicationServer (BTW: internally used by
KGameNetwork - no need to use outside of libkdegames):
It is started by KGameNetwork::setGameMaster(true) and doesn't accept network
connections by default. Call initNetwork() to change this. By calling
setGameMaster(false) it is deleted. Note that you should not call this directly,
as no more communication is possible! Use KGameNetwork::connectToServer instead 
(which calls setGameMaster(false)).


[prev in list] [next in list] [prev in thread] [next in thread]