Author Topic: Slaves and Massmsgs (Read 4179 times)

Naturalistic · « **on:** December 14, 2005, 04:48:09 am »

We had a bit of a discussion in iRC earlier about making a few slave bots for Bebot to link with when sending mass messages. What does this mean? When sending 1 mass message, it's only every 2 seconds a /tell is sent out. With the slaves, we can have the main bot make each slave send a mass message /tell according to the list of members that specific bot has. This would greatly increase mass msg speeds

There was however, many ideas of how this could be accomplished. Which we could use more ideas/suggestions with

Using the database of members, have a table set for each of the slave bots to control which members are sent a /tell. Or, load up all the members onto the buddy-list according to that table, then compare for online users then send out the /tells. Anyone have some ideas on this?

As for contacting the slaves, we would use 1 /tell to each bot to start sending mass messages.

I believe this is mainly what was discussed, but I'm sure that others can add onto what I've posted

Cheers.

Akarah · « **Reply #1 on:** December 14, 2005, 04:58:50 am »

it would be cool if we could link them up out-of-game through a named pipe or socket or something.. then the bot would be free to respond normally to other user commands like !online and such while it is processing a massmsg. (just another idea, i hope to have a couple more soon.

)

Alreadythere · « **Reply #2 on:** December 14, 2005, 12:58:23 pm »

Communication could be done over a table for each spam client. Make the main bot put the name of the receipient, the messege and a timestamp into a table for the slave. On the slave there is running a cron job that checks for messeges to spam with timestap < time(), it takes them out, handles them, and then deletes them out of the table. So the actual work of spliting the tells over clients would be done on the master, but only as table inserts - which are pretty fast. And the dedicated slaves just have to check the database, and spam their targets.

Akarah · « **Reply #3 on:** December 14, 2005, 07:06:25 pm »

doesn't sound like a bad idea

Naturalistic · « **Reply #4 on:** December 14, 2005, 09:08:56 pm »

Well, yes and no.

You need to keep in consideration the actual servers restrict a 2 second delay between /tells. So if you add a cron job for the slaves to 'check' a table for a job, that would add more seconds. Meaning a bit longer mass message.

Admin sends a /tell to main bot, main bot then has the slaves send send out messages to their respected lists of users. So I'd agree to put all the names into a table, maybe a separate one, to get a list of who to add to buddy list, but that's generally checked when a massmsg is sent. When a new member is added, it goes into the lowest count of users for a table, if all the same, add to the first slave. The bot takes the table, checks the online users, then sends the messages. I think generally that would be one of the fastest ways.

Glarawyn · « **Reply #5 on:** December 14, 2005, 09:41:18 pm »

I think most bots use 2.2 seconds between tells for good measure.

What's needed is a trigger to tell the slave bots to go into action. Either the slaves query the database every 2 seconds, which I think is a waste of CPU, or your master bot triggers the other bots with a chat command.

Using tells, there would be a 2.2 second delay between triggering each bot.

However, you can spam private group endlessly without delay. I once tested this with a quick and dirty module that would generate X lines of text in pgroup as fast as possible. I spammed my private group with 100 messages and didn't have any issues.

What I would do is have the slave bots listen to the master's bot channel. Use a different command prefix for the slave bots, # instead of ! or whatever.

/tell mainbot !alert Alert Message here

Mainbot figures out who's online, how many and which slaves are online, devides number of people by number of slaves, then in private group does:

Code: [Select]

[Mainbot]: Mainbot: #salert <A href="text://Character1,Character2,Character3">Slavebot1</a> <a href="text://Character4,Character5,Character6">Slavebot2</a> <a href="text://Character7,Character8,Character9">Slavebot3</a>

The slavebots just have to parse out their list of names and send the alert to that list.

Naturalistic · « **Reply #6 on:** December 14, 2005, 09:53:23 pm »

I like that idea. But one thing, where and how would the slaves get the user lists? tables or do the main bots handle which bots send to who etc? I think that's one of the biggest questions.

Khalem · « **Reply #7 on:** December 15, 2005, 05:15:34 am »

Just from the top of my head. I do believe AO allows you to send x tells within x seconds before the flood limiter kicks in.

On a side note, having a 2 second delay on the tells that starts the messages on the slaves isnt a large delay.
If you have say 5 slaves, we are talking about a 10 second delay. That delay is quickly recouped as the 5 bots are able to send out the tells 5 times faster than the single bot would.

Also, the idea of using a socket is a nice one. It does introduce more complexity, and there are also issues related to security/access control to consider. But overall that is the absolutely best solution in terms of extendability. It could also be extended to cover the IRC relay aswell as handeing bot <-> bot relay. Currently bebot relies on tells to transport messages between guildchats, and with it the obvious limitations that the AO Chat socket impose.

Another possibility that was discussed briefly would be the splitting up of the actual buddylist across multiple bots. That way you would combined with a mechanism for proper inter bot communication keep an constantly up to date list of online users bypassing the 1k character limit. It could also facilitate logon messages and proper "last seen" tracking.

Wolfbiter · « **Reply #8 on:** December 17, 2005, 09:10:09 pm »

Shared memberlist and "limit X,Y" is probably the best way to split up. That way you never have to add new users to specific bots with all the extra hassle that is.
This way you just set global variable X and Y.

Bot1 would do "limit X,0"
Bot2 would do "limit X,Y+(Y*0)"
Bot3 would do "limit X,Y+(Y*1)"
Bot4 would do "limit X,Y+(Y*2)"
and so on.

Just have to code into each bot so it knows how much to * with.

Khalem · « **Reply #9 on:** December 25, 2005, 01:21:45 pm »

Since tells is the most likely thing being used as a trigger, there should be aknowledgements sendt back to the master aswell to prevent tells from being lost if a slave is offline or doesnt confirm having sendt out all tells.

Possible example negotiation:
Master -> Slave1: announce 1-200
Slave1 -> Master: confirm 1-200
Master -> slave2: announce 201-400
Slave2 -> Master: confirm 201-400
Master -> slave3: announce 401-600
(no responce from slave3)
Master -> slave4: announce 401-600

Once all messages have been sendt by a slave it should tell the master again freeing it up for the next batch.
Slave1 -> Master: complete 1-200
Master -> Slave1: announce 601-800

The amounts of announces a slave is asked to do in a batch should be large enough that the master wont end up delaying tells if it has 10 slaves, and small enough that it can be complete a buddy add/remove cycle quickly and not encounter a situation where a single slave is still sending out 100 tells, while 5 other slaves sit with empty tell queues.

Nesi · « **Reply #10 on:** December 26, 2005, 10:46:30 pm »

A decent idea i think, but is it really needed for a mass invite?
People usually know what each bot is for and therefore why they have massed. And the privgroup invite popups are instant.

Khalem · « **Reply #11 on:** December 27, 2005, 06:48:47 am »

The slaves are not needed neccecarily for the mass invite (the actual invite has to be done by the master anyways), however when it comes to the announce spam, and also mass tells during normal operation of a raid bot, the slaves come to their own right speeding things up.

Remember, we have a limit of one tell per 2 seconds or so (2.2 or 3 if you want to be carefull), when you are sending an announcement to say 300 concurrent users (10% of the total memberbase of a decent sized raidbot) that announcement will take 300 x 2 seconds to send, thats 10 minutes for all of them to merely recieve the announcement, provided there isnt a single higher priority tell needing to be sent which will add another 2 seconds delay before complection. If we use 5 slaves, that would bring the time needed to send those 300 tells down to a mere 2 minutes

Naturalistic · « **Reply #12 on:** July 19, 2006, 11:31:51 pm »

This subject is kinda scrapped for public use.

Been thought over, there's too many ways slavebots could be abused.

We'd like to remain on Funcom's good side, and not have them remove bots from us