• v1.12 A39 Linux/64 Compiled 2018/04/12 00:20:14

    From bcw142@21:1/145.3 to g00r00 on Friday, April 13, 2018 10:05:47
    v1.12 A39 Linux/64 Compiled 2018/04/12 00:20:14 does clear up the mis
    dropping out that occurred in 04/08. Much better from what I see, we'll see
    how many days it will run. The 04/08 version generally didn't last 24 hours
    in the Linux version, had drops in the Windows 10 64 bit version as well.
    So good work.

    --- Mystic BBS v1.12 A39 2018/04/12 (Linux/64)
    * Origin: Workpoint (21:1/145.3)
  • From g00r00@21:1/108 to bcw142 on Friday, April 13, 2018 17:21:08
    v1.12 A39 Linux/64 Compiled 2018/04/12 00:20:14 does clear up the mis dropping out that occurred in 04/08. Much better from what I see, we'll see how many days it will run. The 04/08 version generally didn't last
    24 hours in the Linux version, had drops in the Windows 10 64 bit
    version as well. So good work.

    Very interesting. I have had none of those experiences here.

    I have a telnet test running right now on the latest pre-alpha in Linux it currently has served 134,000 connections (as many as 25 active nodes at once) without a single crash or ghost node...

    Its been running for many hours with a huge load. I wonder what I do different because I never see crashes and ghost nodes.

    Yesterday I did a HTTP server test with *1.75 million* connections as many as 200 users at once and no crashes or issues.

    I wonder if it could be the servers used or settings that I am missing? Or that I am always running the "debug" version... I just don't see any stability or ghost node issues. What servers do you use in MIS?

    --- Mystic BBS v1.12 A39 2018/04/12 (Windows/32)
    * Origin: Sector 7 [Mystic BBS WHQ] (21:1/108)
  • From bcw142@21:1/145.3 to g00r00 on Monday, April 16, 2018 07:19:59
    On that 04/08 version I ran 'sudo ./mis DAEMON'. Maybe it's DAEMON mode that had the issues, anyway the 04/10 seems fine so far. The difference for me is constant attacks from Russia and China with out of bandwidth data and junk of every type and breaks, drops and anything they can think of to disrupt the session so they can brake in to the OS. You do clean connections, so they
    don't ghost. You need to do things like send four bits (not a byte) and then drop connection, then pound on it with more then 60 connections in a minute (sometimes over 4 in a second). That and viruses in extra data on each connection (hoping for an overflow and execution of the extra code). That's
    the type of stuff I get hit with.

    --- Mystic BBS v1.12 A39 2018/04/12 (Linux/64)
    * Origin: Workpoint (21:1/145.3)
  • From g00r00@21:1/108 to bcw142 on Monday, April 16, 2018 16:27:23
    clean connections, so they don't ghost. You need to do things like send four bits (not a byte) and then drop connection, then pound on it with more then 60 connections in a minute (sometimes over 4 in a second).

    The load tests I do are signficantly more than the 60 per minute you're getting (I've done up to 15,000 per minute). I hadn't done one in a few builds though, and I did end up finding a bug in the build you had crash. It has now been fixed.

    What I do is I simulate anywhere from 50 to 250 users who connect, get ANSI detected and then enter an unknown name into the BBS. They then wait for a random amount of time (anywhere from 1-6 seconds) and drop connection at the "Apply as new user?" prompt.

    I am running one right now as we speak with 100 users on the latest pre-alpha build running on Ubuntu/64 16.04 LTS. All 100 nodes are full. Its up to 35,000 connections at the moment with no ghosts or crashes (up to 6,000 per minute).

    I'll probably run this up to about 250,000.

    --- Mystic BBS v1.12 A39 2018/04/14 (Windows/64)
    * Origin: Sector 7 [Mystic BBS WHQ] (21:1/108)