Crossfire Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CF: Multiplying inventory



On Mon, Dec 07, 1998 at 02:40:23PM -0800, Mark Wedel wrote:
>  But this opens up the other trick - get into a treasure room, loot it, kill
> the connection, wait for the map
> to reset, loot again, repeat if desired.

Doesn't this work even without the modification? save, kill client and wait for
map-reset?
>  There is the ban file which should already take care of that (or so I
> thought).   I don't know what libwrap does, but anything that does dns lookups
> is not something you want in the server (unless you do it in a different thread
> or something so it doesn't block.)  Otherwise, if some user comes from some
> domain with a very slow dns server, the game would freeze for all players while
> it is doing the name lookup.

The ban file is a bit restricted. Allow file would be better :)
For example, if connection from one IP is to be allowed, one would have
to put all the other godzillion (256*256*256*255) IP's to the ban-file.
I doubt that the server would be a bit busy at every connection attempt,
don't You? 
Allow file is nicer, so one can do a 'allow .pyrsonal.org' to allow
whole domain in. 
Apart from the obvious problem (above) there's the question about logging.
Libwrap  know about the standard unix logging system, so every connection
(accepted or rejected) are logged appropriately. 
It's only a matter of bit of coding to go around the blocking dns lookup.
Fork the lookup, and check for finished lookups in the server loop.
Shouldn't be overly difficult to implement.
-- 
BSc. Pertti Karppinen <pjka@iki.fi>                   |'Bridge Players |
Systems Designer, University of Jyvaskyla, Finland    |      Do        |
http://www.iki.fi/~pjka/ | Office  : +358 14 602 088  |      It        |
HAM: OH6KTR QTH: KP22UF  | Cellular: +358 40 564 0786 | on the Table'  |
-
[you can put yourself on the announcement list only or unsubscribe altogether
by sending an email stating your wishes to crossfire-request@ifi.uio.no]