I see a lot of quick exit/enter pairs in the log. Were these all unexpected drops?

04:45:48 PM 11/15/2010 Sing(1): Normal exit
04:45:51 PM 11/15/2010 98.214.81.211 Sing(1): Ran Tradewars 2002.

04:48:56 PM 11/15/2010 Sing(1): Normal exit
04:48:57 PM 11/15/2010 98.214.81.211 Sing(1): Ran Tradewars 2002.

05:53:27 PM 11/15/2010 Sing(1): Normal exit
05:53:28 PM 11/15/2010 166.196.73.113 Sing(1): Ran Tradewars 2002.

05:54:35 PM 11/15/2010 Sing(1): Normal exit
05:54:36 PM 11/15/2010 98.214.81.211 Sing(1): Ran Tradewars 2002.

06:15:03 PM 11/15/2010 Sing(1): Normal exit
06:15:04 PM 11/15/2010 98.214.81.211 Sing(1): Ran Tradewars 2002.

06:29:10 PM 11/15/2010 Sing(1): Normal exit
06:29:11 PM 11/15/2010 98.214.81.211 Sing(1): Ran Tradewars 2002.

06:37:12 PM 11/15/2010 Sing(1): Normal exit
06:37:13 PM 11/15/2010 98.214.81.211 Sing(1): Ran Tradewars 2002.

06:45:07 PM 11/15/2010 Sing(1): Normal exit
06:45:08 PM 11/15/2010 98.214.81.211 Sing(1): Ran Tradewars 2002.

08:09:55 PM 11/15/2010 Sing(1): Normal exit
08:09:56 PM 11/15/2010 98.214.81.211 Sing(1): Ran Tradewars 2002.

If these were dropping you all the way out of TWGS, I'm not getting any calls to the normal TWGS close session routine, which would mean that whatever is causing this is outside of the normal sockets processing entirely.

Around 5:30pm, I started having ISP problems. They aren't
relevant to the CIM bug, but they are drops. Most of those
were full disconnects.

The 04:45:48pm exit looks like the one I'm talking about.

That wasn't an exit-enter, it was my relog. My relog catches
the issue very quickly and brings me back in.

Hmmm, ok. Just trying to sort this out. How was the first one was different from the rest?

I've added some code to log whenever I receive a close socket event from the socket. Normally, this happens after TWGS starts the process of shutting down a session. It tells the client to close the socket, and the client does so, generating a sockets close event. That's the normal shutdown process for a session. The shutdowns you're seeing are not following this routine. The first thing TWGS seems to be seeing here is a socket close event, which means the drop is being instigated from outside of TWGS. Of course that doesn't necessarily mean that TWGS isn't to blame. There could be some kind of error that's happening that's causing the client to drop the connection. But looking at the changes I made when this started happening, there just isn't any obvious cause. And there doesn't appear to be any pattern to it either. It seems to happen frequently for a short time, then goes hours without happening. I asked before if there was a pattern to what you were doing when these drops happen, and you said CIM reports, but I've tested that extensively without a single drop myself, so no help there.

Could you jump onto the twgs.21-6.com server and see if you can duplicate this there so I can see if it's specific to this site?

Actually I've been playing on the beta software for weeks and it seems I had more disconnects on the old software than the beta software.

Sing, could you do me a favor and go to twgs.21-6.com and see if this disconnect bug is still happening? I installed some earlier versions and my tests show that the disconnect is happening all the way back to TWGS v1.03, the version that's been out for years. But I'm not sure if what I'm seeing is the same thing you're seeing.

I'm running the current public release, v1.03, on twgs.21-6.com right now just to test this out.

When I get a chance, I will.

Ok, I logged in but there's no way I can test it. It's only got 1000
sectors, and that isn't enough to test for a timeout. Would need
a 30k with enough turns to grid it up so I could test for port and
sector CIM.

Ok. I guess I need a lot more detail on what's happening when you get this drop. I thought it was happening even if you weren't doing anything, just sitting at CIM.

I figured out that the drops I'm getting are caused by my ISP, so there's probably no reason to test this on that version anyway. I'll get the latest back up there soon.

Running a port and/or sector CIM.

Thanks, Sing.

I have been playing on the Toyland beta and have not timed out during a CIM ever. DOnt know why but just throwing the info out there,

No timeout reports on Silver Wings Either. Maybe it's server or tedit setting related.

Are there multiple people experiencing this on classictw.com? I just can't seem to reproduce this. I set up an Ambassador account with full "known" access to all sectors and ports, and I spent a few hours generating CIM port and sector reports without any problems. Based on the information I've been given, I just cannot reproduce this bug.

If the bug is dropping all the way out of TWGS without any display, then it's definitely not being caused by anything in the game. It can't have anything to do with CIM processing, for example. And I guess I don't understand how you can tell the difference between a drop because of the ISP and this drop. How does it appear different?

When the ISP drops, my cable lights go out. That was what
was happening last time, the entire ISP would drop out
completely.

I only notice the problem on 30k unis.

But if you can't reproduce it and others aren't having the
problem, then don't worry about it. If it happens later I'll
let you know the exact time when it happens.

I wonder if it could be related to the problem we looked at before, where chunks of output are being dropped when the buffers are overrun. I'd be surprised if that's happening with the CIM I or R, because those are held to a pretty slow pace, only about 100 sectors or ports per second. But the amount of data coming through could be the trigger here.