3-Server BC Bot

Lumi sent me this a long time ago and told me to keep it between us, but since he has not been around for a while and this is valuable information, I will share it with the forum. As the title says, it is a download that allows you to run your bot on all three servers so you never waste IPs. It is also possible to just run 2 of the bots for 2 servers. I am not sure how it handles BE's, but you can play with it and see. More than likely, if you are running the 3 bot version and one server goes into BE, it will continue on the other two. Just play around with it and see. Anyway....

Here's the whole setup you'll need:

http://rapidshare.com/files/299781409/MultipleBCs.rar.html

It's made on a 1024 x 768 resolution screen so hopefully that's close enough to what you're running. If not, you're going to have to play with the placement of "BC Shortcuts" window to get it just right. I included 2 pics to give you a better idea of how it's setup on my computer.

An important point to make: I think you're probably going to have to delete the 3 shortcuts in the BC Shortcuts folder because they won't open properly once transferred to a new computer. Just delete them and create new shortcuts for each bot and put it in the folder so it's the same as it is now.

Give it a test run and see how it goes. Edit the config.xml file and just fill in random brutes for the test run if you want. To start it, load up the FR bot and choose to create pupils. That should start the automated sequence. The ES bot should be the last bot to run. Once it's done. It should close itself and will click twice on the browser in the background. That's how I needed to change IPs on my dsl connection. You'll have to edit this part so it changes IP for your setup.

Good luck forum :)

Maybe you should make a new package and update the link:

Spoiler:

Nice. I was thinking about that for some time (and I'm still thinking about it). If I have time I will instead modify the Java code and recompile the BC jar with multiple servers COM/FR/ES (if there's no protection on the BC server) which would make a really clean multiple server BC (identical to what's existing now, just 4 more masters to specify in config.xml).

EDIT:
In the meantime, it is rather easy to build such a COM/FR/ES setup with the "official" BC version:

1. Create 3 BC installations, each of them for a given server (COM/FR/ES), of course in different directories.
   
2. Say the first BC installation for COM has a real *.bat IP Resetter as usual.
   
3. The two other BC installations for FR and ES have blank *.bat IP resetter that does nothing at all and a fake IP Getter that just return a random IP (you have either to create your own fake IP Getter or find a page on the internet that shows different first characters each time it is loaded). For these two installations the delay for the creation of pupils must be shorter than for the first BC installtion (say two times shorter).
   
4. Run the "Création automatique" for all 3 BC installations: that's it!
   

Why does this work? The first BC installtion for COM creates pupils as usual and changes IP, while the other BC installations just do create pupils (without changing IP which is not necessary) at a sufficiently high rate (because the delay is shorter) so that between each IP reset you can be sure that the FR and ES BC installations created at least one pupil for each master.

Sioc wrote:

Maybe you should make a new package and update the link:

Spoiler:

Sorry. Didn't know the link was out... I don't know if I still have it though. I'll look later.

@ sioc, for that temporary idea to work, you'd have to be able to ensure that all the bc's are running synchronized so that the ones using spoofed IPs don't miss the window of opportunity for proper creation while the main one is using the real IP changer. If one of the spoofed bc's reconnect is off by a second or more, after a certain number of runs, it would get its creation cycle interrupted when the router/modem resets for real. That interruption and loss of an IP on the secondary bc's may not happen very often, and for those with larger IP pools, a few IP's won't be missed, but for those with smaller pools, every IP is precious

Using Lumi's idea as a base, I modified several things for Yab, myself, and a few others when they requested (I did it on their computers personally to make sure it'd work).

the setup I used before lumi's idea was more complicated - all three would run at once like this:

Spoiler:

lumi's method for running three at once was:

Spoiler:

and, he made sure to use the FR server first, then ES, then COM last to help ensure that if you had FR masters to pupil, they'd get their pupils before the bot masters would take theirs so the IP wasn't wasted.


(I am only posting this since it seems to reveal the technique, as you said, Yab )


so, for those that have experience with minor scripting, running all three separately using Lumi's style is best, and for those with no experience, Sioc's method will work just about the same

bamb@m wrote:

@ sioc, for that temporary idea to work, you'd have to be able to ensure that all the bc's are running synchronized so that the ones using spoofed IPs don't miss the window of opportunity for proper creation while the main one is using the real IP changer. If one of the spoofed bc's reconnect is off by a second or more, after a certain number of runs, it would get its creation cycle interrupted when the router/modem resets for real. That interruption and loss of an IP on the secondary bc's may not happen very often, and for those with larger IP pools, a few IP's won't be missed, but for those with smaller pools, every IP is precious

No.
Because the delay for the two other BC setups are shorter and they have a fake IP Getter. So they don't have to by synchronized in order not to miss any pupil.
Moreover if the main BC that changes IP is a FR one then by properly reducing the delay of the other BCs you don't waste any IP on COM/ES as for Lumi's method.
I've done some tests and it seems that after a loss of connection while BC is pupilling it continues once the connection is back (may indeed be wrong here and should do more testing though).

But I do prefer Lumi's method as well because imo starting over everytime with a fresh BC seems more stable than letting the same BC instance running all time.

hmmm ca me fait penser a un truc que j'ai fait , j'ai pas le temps de traduire mais si Sioc juge utile ce script je suis sur qu'il le fera ( ou pas^^ )

il faut arriver a synchroniser les BC ensembles, et ça c'est possible a l'aide du resetIP.bat, avec un script php qui vas checker la connexion

exemple de ce que j'ai fait pour un membre: http://www.megaupload.com/?d=SOARF1Z8
avec création sur 6 brute simultanément ,

ici on utilise un script perl pour rebooter, après a vous d'adaptater votre reboot ( dans le .bat, un petit "start c:/votrereboot.exe ou ajouter les ligne batch),
explication du fonctionnement :

Spoiler:

Ok, I won't translate everything but this is yet another interesting route. This one makes use of a PHP script to synchronize all 3 BC instances that run simultaneously.

Spoiler:

First BC directory in winni's file will trigger IP resets through that PHP script. Other two instances are "followers".
Yet another interesting route imo, seems quite straightforward to use but didn't test it though (pretty happy with my current 2-server BC bot atm ;-) ).

To sum up the 5 routes:

1. w13winni: 3 simultaneous synchronized BC instances, no BC restart. At first requires no coding skill at all because winni already did everything (but I didn't test it though). Drawback: stability issues if BC is not restarted, IPs given away cannot be recovered.
   
2. Luminous: 3 non simultaneous BC instances, BC restarts each time. Requires a bit of rather easy scripting and the fact that BC restarts every time yields a more stable routine. Drawback: you can't reconnect faster than the whole process of loading up the 3 instances of BC, IPs given away cannot be recovered.
   
3. Bamb@m: 3 simultaneous artificially synchronized BC instances. Requires some ease with scripting (Actionaz or Winautomation). Drawback: same as for w13Winni's route.
   
4. Sioc: 3 simultaneous non synchronized BC instances. Requires a fake IPGetter (not mandatory!) but no scripting/coding skill at all. The advantage is that IPs given by BC can be recovered if the delay of instances 2 and 3 of BC is short enough. A priori the less stable of all routes. Drawback: stability issues if BC is not restarted, eventually some problems if the connection is reset just when another BC instance is pupilling (didn't encounter the problem though).
   
5. Modified 3-server BC: not yet!
   

Well, depending on your skills and knowledge you can now choose the route that suits you best ;-)
Personnally I'm using a hybrid version of Luminous' route and Sioc's (taking advantages of both routes: restarting BC each time and not losing IPs given away).

Sioc wrote:

bamb@m wrote:

@ sioc,.....it would get its creation cycle interrupted when the router/modem resets for real. That interruption and loss of an IP on the secondary bc's may not happen very often, and for those with larger IP pools, a few IP's won't be missed, but for those with smaller pools, every IP is precious

No.
Because the delay for the two other BC setups are shorter and they have a fake IP Getter. So they don't have to by synchronized in order not to miss any pupil.
Moreover if the main BC that changes IP is a FR one then by properly reducing the delay of the other BCs you don't waste any IP on COM/ES as for Lumi's method.
I've done some tests and it seems that after a loss of connection while BC is pupilling it continues once the connection is back (may indeed be wrong here and should do more testing though).

But I do prefer Lumi's method as well because imo starting over everytime with a fresh BC seems more stable than letting the same BC instance running all time.

since I only have my own ISP to use, I can't be sure either, but since yours would continue after resetting, and mine would lose the pupil, and assuming I remember correctly that your reset is only a few seconds (mine takes a minute per reset), I'd have to assume if the connection loss is only a few seconds it's ok, but if longer, you'll lose it like in my situation.

Sorry for the dum question, but this 3 server bot is to use 3 diferent BC simultaneous in wich each one is for COM, FR and ES, right?
This way we could pupil through the 3 different servers without waste the IPs.
How do I make this work? Cause when I start BC1, it doesnt pass to BC2 or BC3 whatsoever.
I have to make it manually. Shouldnt do it automatic?

Read our posts above, yes, here, just a few lil'posts above...

Yes, I have read it, but still didnt understand how to automatic pass from one BC to another.

Version 1.3.00 is now a 4-server bot.
All this is not required anymore.
Locking down topic.