Server Help

[dugwyler]

As some of you probably know, I've been working on pushing the limit of client-side bots on Subgame, much in the way in which Hyperspace was originally. Basically what I have is a bot that sends out a lot of chat packets, in the form of prizes and various interface messages. The project is moderately successful so far, but a couple of problems still remain:

- When too many messages are sent out at a given time, a server recycle is initiated. Sometimes this is preceded by what appears to be a biller outage, though one time this occurred it seemed local to the arena in which the game was being hosted. This issue appears to have been fixed by implementing a more stringent prizing queue with small delays between each prize, and a spammed message delay so that for each cluster (TWCore sends a cluster of packets out every 75ms by default) only one message in the spam is being sent. Other messages remain unregulated.

- After the above problem was fixed/hack-fixed, the bot began getting randomly DC'd after a few hours of uptime. Frustrated with the generic message, I modified it to be more explicit about the reason of the DC, and found that it is disconnected because it's receiving the kill order from the server (bidirectional packet 0x07).

More annoyance. I modified the outgoing packet sender to make chat packets of a lower priority by putting a cap on the number allowed to be sent out per cluster (no limit on other packets). But I haven't played with this yet because I just came across an unverified statement tucked away in the comments about being careful to not to adjust the (cluster) packet send delay too much or you'll risk overflowing the 2500 packet/minute limit. I've never heard of this. Also thought that if there were any such thing it would be by byte count and not packet count. I asked Mythrandir about it and he's pretty sure DoCk> wrote this particular comment, so he's considering it pretty reliable considering the tie to Priit.

Is anyone familiar with this limit, and know for a fact that this is when Bi-dir 0x07 is sent? If so it looks like the work will be easy -- just limiting the number of packets per minute, and probably only allowing non-chat packets when there are only 50-100 packets remaining before the limit is reached. Meanwhile the chat packet cap per clustered send should prevent the recycle that seems to happen when a rush of chat packets are sent at once. Or is this the wrong tree up which to be, uh, barking?

Also, do you think if a bot core were run locally where a server is hosted, these limits would disappear, or at the very least be severely relaxed?

[Dr Brain]

We ran into all these problems with the AreaBots and never really fixed them. That more than anything else forced us to become the first adopters of ASSS.

I do recall that the bot died pretty quickly in highly populated arenas, and less quickly in less populated arenas.
_________________
Hyperspace Owner

Smong> so long as 99% deaths feel lame it will always be hyperspace to me

[dugwyler]

How populated is highly populated? We're running anywhere between 30-50 players with varying numbers of prizes, though no player is prized at the same time as any other. Also, did you ever have a chance to run the AreaBots from the same place as the SS server?

I did a quick test to see if I could beat the 2500 packet/min limit, and it was pretty easy. The bot prized me around 4700 full charges in about 30 seconds. After that a packet flood warning message came up with my IP rather than the bot's, and I was DC'd. The bot remained, though. A few other tries: I wasn't able to keep up with how fast the bot was prizing and was DC'd after about 7 reliable packets lost.

Next I had one bot prize another rapidly. This lasted several minutes. Rather than the prizing bot being DCd, the one being prized was disconnected with a bi-dir 0x07. The log showed the same message about reliable packets being lost, though it lost far more (a full *log worth).

[Cheese]

interesting workarounds.

unfortunately for distension, the limits are quite limiting indeed.
these limits cant be passed until tw adopts asss.
which will never happen.
_________________
SSC Distension Owner
SSCU Trench Wars Developer

[Dr Brain]

At 60 pop, they'd be dying about every 4-5 minutes. I have no statistics about packets though.

Yes, the bots were always hosted on the same machine as subgame.

[Guest]

try setting misc:botsip in the server.ini

[dugwyler]

I was finally able to defeat these issues. A few changes that seemed to resolve it:

- TWCore was not implementing the LVZ toggling packet (though we did have support for LVZ modification). This cut down greatly on the size of packets being sent out, as we were otherwise using literal text in a message packet -- "*objon 5" and so forth. Another bonus to going this route was being able to cluster several obj toggles into one tiny packet.

- The internal packet limiter was cleaned up a good bit, so that only a certain number of packets can be sent out at a given time. When there's a lot being prized this can cause slight slowdown, though really it's not too bad. This limiter is running on all of TW's bots now, without any real issue. The number of random DCs we have has been reduced significantly across the board.

- Discovered a bug wherein occasionally an ACK packet would be sent reliably. A reliable packet is one that needs to be ACKd by the server -- meaning, the server would have to send back an ACK for the ACK, which is of course completely ridiculous. It's estimated that one bot running on TWCore before this change sent out a "reliable" ACK every second. Multiply that by 40 or so and you have a lot of unnecessary ACKs of ACKs running S2C. No idea how much this cut down on load, but it was a good find.

I'd say that after this TWCore is pretty much OK to run these sorts of RPG-style upgrade games, with some limitations. Namely: you need to either set the internal packet limiter to a "sweet spot," or implement an upgrade queue so that when a lot of people need to be given their upgrades it's not all done at the same time.

For those interested, you can get all these changes by creating an SVN read account from TWCore.org. Also feel free to look at the publicly-available code of DistensionBot for implementation of the queue or the upgrade system in general. Welcome to rip anything/everything there if you want to do an upgrade-based game running on Subgame.

Would be particularly cool to see someone do one of these using map exploration, now that *sendto can force a person to another arena on certain conditions such as edge of a map.

[Samapico]

edit: nvm
_________________
(Insert a bunch of dead links here)