[Freeciv-Dev] Re: (PR#4594) topology fix for goto route packet

["rwetmore@xxxxxxxxxxxx" <rwetmore@xxxxxxxxxxxx>]

Baumans wrote:
> ----- Original Message ----- 
> From: <rwetmore@xxxxxxxxxxxx>
> To: <jdorje@xxxxxxxxxxxxxxxxxxxxx>
> Sent: Monday, July 28, 2003 6:13 PM
> Subject: [Freeciv-Dev] Re: (PR#4594) topology fix for goto route packet
[...]
>>>The options are:
>>>
>>>   if (!is_normal_map_pos(x, y)) break;
>>>
>>>   if (!normalize_map_pos(x, y)) break;
>>>
>>>   if ((x == 255 && y == 255) || !normalize_map_pos(x, y)) break;
>>>
>>>The first has the disadvantage that client must send only normal
[...]
>>>The third has the disadvantage that if the client actually sends any
>>>non-normal positions you'll end up with buggy behavior: eventually
>>>they'll send (255,255) and have their goto route prematurely terminated.
>>
>>No disadvantage ... (-1,-1) has always been a special case, and can
>>certainly continue to be one in the future.
> 
> What if the client sends (-1,-1), in the torus topology?  The server can't
> tell what this means: is it supposed to terminate the route or go to the
> normalized (-1,-1)?  The only way it can know what to do is to require that
> the client not send (-1,-1) except as a special case, and we're back to
> restricting the client.  (-1,-1) used to work because that never used to be
> a real coordinate.  This is also applicable to (255,255).

First, (-1,-1) has always been the invalid coordinate flag, it has always
been special and has been used by the clients in the past for this. It is
used on the server too and is being used in new code going in daily. This 
problem needs to be fixed everywhere for gen-topologies. One really does
need a "not-a-coordinate" coordinate concept and gen-topologies breaks the
current definition. One should not just ignore the underlying problem of
how to deal with this special coordinate with local hacks like (1).

This has never been a concern before gen-topologies since (-1,-1) was never
a valid aka real coordinate, thus only gen-topology code changes are needed
to *fix* any clients, i.e. old clients don't need any fix, but they will
continue to send (-1,-1) to new servers. Jason's *fix* makes this a bug,
while (3) preserves the backwards compatible standard and works with all
clients. (3) is actually more efficient code too.

> You cannot deal with this in the server.  If you want to deal with it in the
> client, why don't you just normalize?  The only other option is to hope and
> pray that this never comes up.

You can normalize, or just fix any (-1,-1) real coordinates (which probably
needs to be done where they are created), that you might send over the
network in cases where they are now subject to misinterpretation. This is
only code needed for new clients with the gen-topology patch. You could
also build a fix that catches the error return from a (3) solution and does
a fixup/resend. This is the "exception" style of coding that avoids
cluttering up the expected codepath with unnecessary special case code. The
fact is there are many solutions, and not just the blanket (1) fits all.

Testing for one special coordinate is fast, normalization is slow and must
always be done on the server anyway for it to guarantee its integrity, so
why do it twice. But basically, there is no need to change the treatment of
every coordinate, just deal with the one special case as part of the
gen-topology list of things-to-get-right. Again, I think the solution to
this is at source creation, and not as a blind low-level network hack.

I have also played a lot with this *not* fixed on the client. It really
isn't an earth shattering problem to have some client operations fail
cleanly even when they should have worked. Thus the full client fix is
the lesser part of this problem if you have the server (3) version in
place. Breaking all old clients and forcing unnecessary conditions on
clients for the forseeable the future is much worse of an issue.

>>It has *no* impact on any  other normalization issues as long as you deal
>>with it first, i.e.before applying some generic normalization. There is
>>nothing buggy in normalizing any other coordinates as they are not and
>>have never been special.
>>
>>The only *bug* is a religious issue about treating special cases as
>>special cases - but that is just the way life works sometimes :-).
[...]

Cheers,
RossW
=====