Today, Emil Nilimaa spake to the list:
> SYSERR: gethostbyaddr: Connection timed out
> Sep 20 19:19:11 :: WARNING: EOF on socket read (connection broken by peer)
> Sep 20 19:19:11 :: Losing descriptor without char.
> Sep 20 19:19:11 :: SYSERR: Missed 80 seconds worth of pulses.
One might assume that you have a slow nameserver, then, or its just this
guy's site that you're having problems with. gethostbyaddr() is a
blocking function, which is a non-factor for people with fast nameservers
(thankfully, the majority). While on as Implementor type "slowns" and
then see if the guy can login correctly and write down his IP address when
he does. After that, add the following function to comm.c somewhere above
new_descriptor():
int problem_resolving(char *arg)
{
if (!strcmp(arg, "127.0.0.1")) return (1);
return (0);
}
replacing "127.0.0.1" with the guy's IP address. Then, in
new_descriptor(), locate the line that looks like
if (nameserver_is_slow || !(from = gethostbyaddr((char *) &peer.sin_addr,
sizeof(peer.sin_addr), AF_INET))) {
and change it to be
if (nameserver_is_slow || problem_resolving(inet_ntoa(peer.sin_addr)) ||
!(from = gethostbyaddr((char *) &peer.sin_addr, sizeof(peer.sin_addr),
AF_INET))) {
Which probably isn't the most efficient code, but will do (provided it
works: it's Mailer Code) fine. Basically, you can add a bunch of IP
address strcmp()s to the function problem_resolving() to have the game
skip hostname resolution for certain (presumambly problematic) IPs. It's
a little better than the stock all-or-nothing approach, but it's still
imperfect.
Really, if you persist to have these problems with hostname resolution
your options are broad in scope and appeal. You can either set
nameserver_is_slow to YES in config.c and give up resolution all together,
meaning, of course, that you don't get hostnames but IP addresses (which
isn't so bad, and it's fast and easy to do).
Or you could create a separate program to do the nameserver lookups,
perhaps complete with a shortcut database for certain known IPs that would
allow you to do the blocking lookups without interferring with the main
CircleMUD process. The external program would be connected through pipes
or some other mechanism (AF_UNIX sockets), with CircleMUD communicating
the lookup request, and the external program replying with the requested
information (or an error code/message if lookup failed). This could allow
you to either (a) hold players who don't have a resolved hostname, yet,
until the dns-lookup program responds to your enquiry -- this would *not*
block the MUD, you'd simply set the player to a specific CON_ state that
persists in polling for the hostname; or (b) let players without resolved
hostnames into the game and silently resolve it while they're playing.
If you're experiencing massive timeouts with the nameserver, (b) is the
way to go (so you don't hold up other new connections trying to have their
hostname resolved). And, of course, you could do something completely
different from the above two solutions. It's really up to you. May the
source be with you...
-dak
+------------------------------------------------------------+
| Ensure that you have read the CircleMUD Mailing List FAQ: |
| http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html |
+------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/15/00 PST