Complete.Org: Mailing Lists: Archives: freeciv-dev: September 1999:
Re: [Freeciv-Dev] Flags
Home

Re: [Freeciv-Dev] Flags

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: qpkjeek@xxxxxxxxxxxxxxx
Cc: freeciv-dev@xxxxxxxxxxx
Subject: Re: [Freeciv-Dev] Flags
From: David Pfitzner <dwp@xxxxxxxxxxxxxx>
Date: Thu, 9 Sep 1999 12:46:13 +1000 (EST)

Jerzy Klek wrote:

> A question:
> There is a MAX_LEN_USERNAME limit (in packets.h)  on maximum
> player name and it's quite short (10). Comment says:
> /* Note that MAX_LEN_USERNAME cannot be expanded, because it
>    is used for the name in the first packet sent by the client,
>    before we have the capability string.
> */
> but as there is a iget_string() function now, I think it's safe
> to make it user name longer if I want. Is it true? It's a bit
> annoying when even name Washington is too long... 

Annoying indeed.  iget_string() isn't a complete fix because it 
doesn't help older clients and server from before iget_string().
While its true that such old versions can't connect with the 
current CVS version anyway, because of capabilities mismatch, 
as the comment says, the MAX_LEN_USERNAME problem occurs before 
capabilities appear, so old version may eg core dump or something
else bad rather than cleanly reporting capabilities mismatch.

My intended plan to "solve" this problem was that MAX_LEN_USERNAME
would only apply to the "username" used when the client first 
connects to the server, and then the player's chosen ruler name 
would be separate (and of longer length, eg MAX_LEN_NAME, and also
ideally allow embedded spaces, which are currently not handled 
well in player names).

(This was intended to be in conjunction with other changes,
as outlined in
http://www.complete.org/mailinglists/archives/freeciv-199909/msg00009.html)

But this scheme has not been implemented, and maybe never will...

An alternative would be to take an approach similar to when
we changed to network byte order, and say that connections
to/from old clients/servers may simply fail.  But that
wasn't a good solution then, and I think there should
be other ways to get around it in this case.

Indeed, now that I consider the possibility, here is an
idea for a workaround:
- Add an extra string at the end of packet_req_join_game, of 
  length eg MAX_LEN_NAME, which will contain the new real name;
- Just put empty string, or probably better, truncated name, in 
  the old 'name' field of packet_req_join_game;
- In new version, when receiving a req_join_game packet, check
  whether there is extra string at end (from pack_iter_remaining());
  if not, copy in from old name field.
- Add eg "+long_player_names" tag to the capabiliity string.  

With this, old and new versions will both be able to handle the 
packet_req_join_game (old versions will ignore the extra string 
at the end of the packet), and connection will proceed to stage of 
checking capabilities, and then they will find out they can't 
work together, and cleanly break the connection.

(Note that because capabilities will prevent connection from
proceeding, we don't have to worry much about what happens
with truncated names; the main reason to preserve the name 
as much as possible is just for using it in server log messages 
about the attempted connection.)

-- David

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