[Freeciv-Dev] Re: [RFC] New event handling

[Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>]

On Sun, Jan 28, 2001 at 09:37:43PM +0100, Reinier Post wrote:
> On Fri, Jan 26, 2001 at 08:21:12PM +0100, Raimar Falke wrote:
> 
> >You would also like it
> > if every response (server->client packet) is a copy of the server
> > state. Is this correct?
> 
> Yes, such packages usually contain the state of objects that the
> server and the client both know, or changes to the state.  (For
> instance, the deletion or creation of an object.)
> 
> I would like it not to be seen as a response!  Packets sent
> by the server can be seen as 'responses' when they result from code
> triggered by the server receiving a packet from the client - for
> instance, a unit movement request results in the new position of the
> unit being sent.  This is because the server is single threaded and
> I'm not sure it is a good to see it as a *design* feature which
> I don't think it really is.  The same packets may also be sent when
> something else causes the state to be updated.

Yes you are correct. There are server->client packet which aren't
direct responses of a client->server packet. In the current
note/serial number patch this is denoted by a initiator_sno of 0.

> > Some things like {unit,city,tile,player}_info follow your
> > paradigm.  However the current event handling doesn't.
> > However the current event handling doesn't. An event
> 
> I don't understand what you mean by 'event handling'.
> Things like unit movement or barbarian appearances
> do follow this paradigm.

If an event like "wonder started" is sent to the client this isn't a
copy of server state.

> > An event
> > handling which will follow this paradigm would be an
> > client-generate-event system like mentioned below. But also such a
> > system would have its exceptions: "Nation foo has started building
> > wonder bar". Such a system would be nice but is not our task.
> 
> I do not see how that is an exception.   I can't follow you, sorry :(

An event is the a notification of a change of some server state. If
the code knows the state before the change and after the change it can
generate an event. So the client itself can generate events like "city
grows", "attack lost" and "tech found" based on the *_info packets the
server sends the client. However some state is unknown to the client
like if another nation starts buildung a wonder. The client can't
generate this kind of events.

> > > I think it is a mistake to view server messages as responses to
> > > client requests.  The real logic is reversed: the server updates the
> > > game state at the client side, and the client may respond with
> > > requests to the server as a result.
> > 
> > This point is fishy IMHO. For you the server drives the game for me it
> > is the client. Technical there is no difference.
> 
> I don't understand; I already pointed out the fundamental technical
> problems with writing client side algorithms that behave *as if* they
> can reliably know state information that really exists only at the
> server side.

The fishy refered to the naming of the client->server and
server->client packets. 

                                   you          me
client->server                   response    request
server->client                   request     response
part that drives the game        server      client

> > > What I object to is the addition of a hack to make them seem responses
> > > to client requests - you can't base reliable client-side AI programs on
> > > that approach, it is broken by design.  Whereas, if you program the
> > > client side AI according to the existing programming model, namely,
> > > in terms of routines triggered by updates from the server, that generate
> > > requests to the server, your client-side algorithms will be more
> > > difficult to understand, but they will actually work.
> > 
> > The new system will allow you to add a callback to a request
> > (client->server packet) which will be called if there are packets
> > coming from the server which are results (more exact which are
> > generated during the processing of the request)
> 
> That is, they will turn this into a design feature of the game.
> At the moment you can still look upon the server as event driven
> *internally* although it really isn't.
> 
> > of the former
> > request. It will be very easy to implement event driven code for the
> > client.
> 
> I think depending on return codes will only make it harder.  Plus there
> is the problem of having to teach the server which return codes to
> produce (if you want a dymanically extensible system).

You may take a look at my posting about the current status of the
patch. In the long term every command should be able to return a
meaningful return code. In the meantime it is ensured that the server
will send at least one packet (the final note).

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "When C++ is your hammer, everything looks like a thumb."
    -- Steven M. Haflich