Gammon Forum : SMAUG : SMAUG coding : Lingering Connections? Bug?

Entire forum ➜ SMAUG ➜ SMAUG coding ➜ Lingering Connections? Bug?

Lingering Connections? Bug?

It is now over 60 days since the last post. This thread is closed. Refresh page

Posted by

Gatewaysysop2 USA (146 posts) Bio

Date

Sun 05 Sep 2004 02:40 AM (UTC)

Message

Greetings all,

I found an oddity within whatever dated version of FUSS/SMAUG my current codebase is rooted in. I have been keeping up with almost all the bug fixes to date so unless I missed something somewhere, this might be a problem for other people as well.

In any case, here's the deal. When someone quits the mud they are given the standard blurb/logoff message and then at the point where the connection is supposed to be cut off, they just sort of sit there in their client program waiting to be disconnected from the server. Even if one manually disconnects from the server, whether waiting "post quit" or at any point during play, the connection lingers.

Checking with the firewall or whatever else, you can see the mud listening on 4000 but also "ghost connected" to long-since ended sessions. I can go in, disconnect at the login prompt, then connect again, login and properly "quit", but the end result is two connections showing up where there should be none. It basically tells me that smaug.exe is listening on 4000 and is also connected twice over across the same port to the aforementioned ghosts.

I tried with an earlier pre-compiled version off this site, (not SMAUG FUSS) and this does not happen. When someone "quits" they get the "connection lost" message and there is no lingering connection reported by the firewall software or any other monitoring tools.

Anyway, long story short, it's annoying but fortunately not problematic at this stage (still in dev) and I'd just like to nix it somehow if possible. I saw some posts relating to this but nothing that seemed to pinpoint it exactly, so if anyone has any ideas on where to look I'd appreciate the heads up.

Thanks!

"The world of men is dreaming, it has gone mad in its sleep, and a snake is strangling it, but it can't wake up." -D.H. Lawrence

Top

Posted by

Nick Gammon Australia (23,121 posts) Bio Forum Administrator

Date

Reply #1 on Sun 05 Sep 2004 05:41 AM (UTC)

Message

There was a recent query on this site about MUSHclient not disconnecting properly, which is an outstanding bug report. It seems MUSHclient closes a little too quickly for the TCP/IP protocol, leaving the connection "dangling" at the server end.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Top

Posted by

Gatewaysysop2 USA (146 posts) Bio

Date

Reply #2 on Sun 05 Sep 2004 05:50 AM (UTC)

Message

I actually caught that post, but I'm not sure that's my problem. I seem to be able to replicate this behavior with the built in Win98 telnet program too, so I suspect it's beyond just a client issue. I could be wrong, of course, that's happened before.

I tried searching the SML for some info, but apparently nobody there found a solution either so I don't know. Personally I can't see any outstanding reason to rip the code apart and fix this, because it hasn't had any obvious implications as far as performance is concerned. That and the daily automatic reboot takes care of all these "ghost" connections anyway. Still, I would like to track it down if it's a code issue.

Anymore ideas on where to check in the code if it's not a client problem?

"The world of men is dreaming, it has gone mad in its sleep, and a snake is strangling it, but it can't wake up." -D.H. Lawrence

Top

Posted by Greven Canada (835 posts) Bio

Date Reply #3 on Sun 05 Sep 2004 08:09 AM (UTC)

Message

I beleive that I know what your talking about, and I think that it was discussed in another form a long time ago. As I remember, it was a matter of the file descriptors not being closed properly on the host, and would leave them open with nothing happening. Boborak had some information here: http://www.gammon.com.au/forum/bbshowpost.php?bbsubject_id=3143

I found the function spoken about informative, and it is this

CMDF do_fdcheck(CHAR_DATA * ch, char *argument)
{
        struct stat fs;
        int       i, j = 0;

        argument = NULL;
        send_to_char("FD's in use:\n\r", ch);
        for (i = 0; i < 256; ++i)
                if (!fstat(i, &fs))
                {
                        ch_printf(ch, "%03d ", i);
                        if (!(++j % 15))
                                send_to_char("\n\r", ch);
                }
        if (j % 15)
                send_to_char("\n\r", ch);
        ch_printf(ch, "%d descriptors in use.\n\r", j);
        return;
}

Fairly simple, but it give you a little in game info. Hope that link helps some.

Nobody ever expects the spanish inquisition!

darkwarriors.net:4848
http://darkwarriors.net

Top

Posted by

Gatewaysysop2 USA (146 posts) Bio

Date

Reply #4 on Sun 05 Sep 2004 08:46 AM (UTC)

Message

Well I definitely think the problem could be something along the lines of what you describe, the descriptors not being closed that is. I did check the copyover code and I don't have issues with things popping up after a copyover. This happens before and after a copyover, the ghost connections I mean, so I don't know how related it is to copyover anymore. I haven't tried a newer version of FUSS to see if this happens, but I'll have to do that at some point just for comparison sake.

In any event, if you have any ideas on how to go about fixing this or some way to code in some checks or a quick and dirty way to eliminate these ghosting descriptors, I would certainly appreciate it. I'm definitely no master coder myself, but I like to think I can at least give things a try if people are willing to give me some help.

Thanks again for your help.

"The world of men is dreaming, it has gone mad in its sleep, and a snake is strangling it, but it can't wake up." -D.H. Lawrence

Top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.

16,757 views.

It is now over 60 days since the last post. This thread is closed. Refresh page

Go to topic: Search the forum

top