[Freeciv-Dev] Re: Freeciv Networking/Mac Server patches
[Top] [All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
At 2:24 PM +1000 8/12/2000, David Pfitzner wrote:
>Andy Black <ablack@xxxxxxxxxxxxxx> wrote:
>>
[snip]
>
>Some comments on some of the rest:
>
>> civserver.c.diff
>> A version of the mac option dialog (#ifdefed out due to crashes,
>> hardcoded version used insted, will work on later)
>
>This should be easier to do differently soon, when srv_main.c is
>added and there will be a 'struct server_arguments' which you can
>adjust/place parameters in.
>
updated, included.
>> added gethostname check
>
>I would prefer that you add a function mygethostname() in support.c,
>which returns 0 if not HAVE_GETHOSTNAME.
Done.
[snip]
>
>> console.h.diff
>> updated protos for move
>
> /* make sure a prompt is printed, and re-printed after every message */
>-void con_prompt_on(void);
>+/*void con_prompt_on(void);*/
>+ /*not needed outside console.c*/
>
>In such cases you can just remove the prototype from the header file
>and make the function 'static' in the .c file (with a static prototype
>inside the .c file if necessary).
Done. References in sernet.c removed.
>
>> diplhand.c.diff
>> small (pointless) cleanup of handle_diplomacy_accept_treaty.
>> removed use of extranious data. remove sending of data after next
>> stable version
>
>I agree the check is unnecessary, but its also harmless. Plus if we
>actually did something with the check (eg, log message) this could be
>useful to notice a buggy client, if the client accidently fills in a
>wrong player_from. Removing sending of the data is probably not worth
>doing, because the diplomacy things all send the same packet type, so
>this would require adding a new packet etc. Unless one did a more
>extensive rework.
>
>More worthwhile would be increased checking of the other diplmoacy
>parameters: it seems to me that a third party could insert a clause
>into the treaty of two other players, as the server doesn't check
>that pplayer is either plr0 or plr1? (And since it should be, then
>one of plr0 or plr1 is always redundant?)
Change reverted. Rework included. Probably solved problem. (probably
doubled the size of diplhand.c!) An article/web page I came across on
slashdot (http://www.slashdot.org) is the folowing:
http://www.gamasutra.com/features/20000724/pritchard_01.htm. The topic of
the article is cheating in multiplayer games and how to counteract
cheating. Might be something to keep in mind.
>
>Incidently I would have thought a two-stage acceptance would be
>safer: what if someone adds a clause just _before_ the server
>receives your 'accept' packet (and then they quickly accept
>themselves).
What about spliting the accept packet into an accept (set accept flag)
packet and a decline (clear accept flag) packet? The client should always
send a decline packet after recieving new clauses.
Alternatly, a confirm packet could be sent. Included in packet could be a
complete list of clauses. When the client recieves the confirm packet, all
clauses are displayed, along with a "sign the document"/"back to the table"
button pair. If the user decideds to sign it, a confirm packet would be
sent. If they want to negoiate, an accept packet could be sent? I'll need
to think about the details some more.
>
>> mem.c.diff
>> a few mac (client) related items.
>> mem.h.diff
>> proto for failure_cleanup
>
>Since failure_cleanup() doesn't currently do anything and is not
>called from anywhere else, I'm not that keen on adding it...
failure_cleanup() is used in the mac client. I have a file pair called
mac_mem.[c/h] that is similar to mem.c/h, except for mac toolbox memory
allocation calls. I don't know if it is actually needed. The reason I
created it was the folowing comment in handle_alloc_failure
/*
* Do anything else here (cleanups? safe-save??)
*/
mac_mem.c includes a routine called handle_mac_mem_failure. It is similar
to handle_alloc_failure, but includes the return of the mac toolbox call in
the log. My reasoning had been that any cleanup would probably happen
roughly the same way, regardless of platform.
[snip]
>-- David
Attached is a revised version of the patches, descriptions follow. I
looked at the links vasco gave, but they didn't appeare to be useful (no
support for needed server routines). The attached file is a gziped
tarball, which may be inside a binhex file (I'm not certaint. Binhex is
how my mailer (eudora light) encodes files). If it is in a binhex, Sorry
about the extra retreval step.
Andy Black
Mac Port Manager
aitech.c.diff
alternate memory allocation. needed to compile. (please comit)
aiunit.c.diff
mac keyword conflict change. (please comit)
civserver.c.diff
updated mac option dialog. bypased with hack due to crash problems.
connection.c.diff
use generalized networking.
connection.h.diff
change protos to use generalized networking.
console.c.diff
moved console reading from sernet.c, changed some functions to static
console.h.diff
changed protos for console.c changes
diplhand.c.diff
security patches and lots of rambling comentary. (please comit)
mem.c.diff
addition/useage of failure_cleanup(). see notes above
mem.h.diff
proto for failure_cleanup().
meta.c.diff
prep for generalized networking.
netintf.c.diff
BSD socket networking. Please check, rename to net_bsd.c.
netintf.h.diff
header for generalized networking, some platform dependant typedefs
net_mac.c
mac socket code. not completly functioning.
sernet.c.diff
generalized networking, move of console reading to console.c
sernet.h.diff
moved #define BUF_SIZE to console.h (part of console reading move,
size of SOCKET_0_ISNT_STDIN read buffer)
srv_main.c.diff
added suport for generalized networking. Please test change from
"gethostname(hostname, 512)==0" to "my_gethostname(hostname)", see note
below
support.c.diff
adition of my_gethostname(char string[]). size paramater of
gethostname is suposedly deduced inside. NOT TESTED. I'll fix it (add
length paramater) if anyone has problems.
support.h.diff
proto for my_gethostname().
tech.h.diff
pair of (useless?) macros. one is needed for diplhand.c.diff,
other could be useful.
server.tar.gz
Description: Mac BinHex archive
[Freeciv-Dev] Re: Freeciv Networking/Mac Server patches, David Pfitzner, 2000/08/11
|
|