[stuff about not being able to reboot deleted]
>autoscript starting game Fri Apr 22 06:10:32 EDT 1994
>Fri Apr 22 06:10:32 :: Quick boot mode -- rent check supressed.
>Fri Apr 22 06:10:32 :: Running game on port 4224.
>Fri Apr 22 06:10:32 :: Using lib as data directory.
>Fri Apr 22 06:10:32 :: Signal trapping.
>Fri Apr 22 06:10:32 :: Opening mother connection.
>bind: Address already in use
>autoscript starting game Fri Apr 22 06:10:33 EDT 1994
This is not being caused by the mud code or autorun. The problem
that you are experiencing can be caused one of two ways. The first
and most likely is that you already have a version of the mud up
and running and don't realize it. When the mud boots it's trying to
create its `well known socket' so users can connect to it. If you
already have a version of the mud running then it will still have
the port active and therefore will not let other processes take it.
This problem can also be seen when using a port that is already
in use by another daemon (ie, mailer, finger, etc). A quick solution
is to change the port from 4224 to 4225.
The second cause of this problem can be blamed on your users. Try
issuing the netstat command in /usr/ucb and you should see a line
similar to this:
tcp 0 0 YOUR_HOST_NAME.4224 mail.sni.co.uk.2275 ESTABLISHED
when the mud is executing properly and you have a PC in from the UK.
If the mud crashes or reboots you may run across this display:
tcp 0 0 YOUR_HOST_NAME.4224 mail.sni.co.uk.2275 TIME_WAIT
The TIME_WAIT is caused by the TCP/IP protocol stack. It won't allow
you to reboot your mud because it has a lingering network connection
that may get confused if the server port suddenly came back to life.
I've seen this caused by users who like to switch sessions in tintin,
users who INSIST on trying to immediately reconnect, and users that
have suspended their telnet sessions rather than disconnect from the
mud.
My solution to the above problem was to see the node that was
causing the problem and then politely rake the person over the coals
until he promised not to do it again. I think there is a better solution
but I'm not going to muck with the networking code until 3.0 comes out.
Hope this helps.
Digger (raven.jhuapl.edu 8000)
--
John Phelps, jbp@raven.jhuapl.edu OR jbp@aurora.jhuapl.edu
This archive was generated by hypermail 2b30 : 12/07/00 PST