[Freeciv-Dev] Re: [PATCH] Unit movement

[Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>]

On Fri, Jan 12, 2001 at 06:37:56PM -0800, ccrayne@xxxxxxxxxxx wrote:
> In <20010113013221.A28912@xxxxxxxxxxxxxxxxxxxxxxx>, on 01/13/01 
>    at 01:32 AM, Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx> said:
> 
> :The other introduces a feedback mechanism. Currently there is no easy way
> :on the client side to get the result of an operation carried out by the
> :server.
> 
> As someone who is actively developing an AI client, I agree that there are
> areas in which my task would be made easier if there were more feedback.
> However -- in its current form -- your patch does not help me at all.
> 
> The most serious problem is that the client has no way of associating your
> results packet with any specific event. Even if the client serializes its
> requests to the server [which should NOT be required], at the time that
> the client sends a unit move request, there may already be several
> messages from the server queued for delivery to the client. To be useful,
> the results packet must at least identify the id of the unit to which the
> result code applies.

I also tought about this. I came to the conclusion that implementing a
generic packet number would be too much changes at one time. This
number would be mentioned in the result packet. The patch is only the
first step. The next step would be to add a "receive packets and
handle them but stop after you receive a packet foobar". So
send_move_unit() set report_result, send the request, jump to this
function and if the result packet comes if will be passed to
send_move_unit() and send_move_unit() will return the result. So
results wouldn't mixed up since there is only one result packet
outstanding.

The easiest interface for the code which calls send_move_unit() would
that the result of the move request is the return code of this
method. However if you allow more than one outstanding request (with
report_result set) how do you associate the result packet if the call
to send_move_unit(). The only answer I can think of are multiple
threads. Or you can change the interface. This would put the problems
on the methods which calls send_move_unit().

> In addition, your patch unnecessarily increases network traffic, because
> there is already a feedback mechanism in place for all successful move
> requests, as well as for many failed ones. If the request is successful,
> the server confirms the request by sending a unit information packet. If
> not, things get a bit complicated, as there may or may not be a message,
> and if there is a message, it may or may not have an event code.

As you said it isn't send in every case and the client non-human can't
easily determine the reason.

> 
> What would really help me, and which would take advantage of the research
> you have already done, would be to add the result code to the unit
> information packet, and to ensure that it is sent in all cases.  

I like the idea. Since unit-move is only an example this also means
that to every information packet will be a result code added.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "Transported to a surreal landscape, a young girl kills the first woman
  she meets and then teams up with three complete strangers to kill again."
    -- TV listing for the Wizard of Oz in the Marin Independent Journal