SRL Archive - General Botting Help

Hello guys,

Since today I've got this "problem". Well I won't really say it's a problem, but it's a bit annoying.
Everytime I test my script and have to restart, the pairing with smart can take up to 3/4 min.
Just seems a bit weird. Don't know if anyone could tell me how to fix this? Would be epic though :)

Thanks in advance,

greetz

I think the pairing happens C side almost instantly and the slow end is Java side. @Brandon may correct the hell out of that statement however, as I know he knows more about that.

As for speeding it up… Try just restarting your computer? My random guess is that something is happening that's taking up a lot of Java's VM memory. Who knows if that's even remotely correct though…

Are you sure its the pairing client (iirc that times out after 10 seconds) but actually spawning a client?

Is it just SMART or is it also slow in your browser/game client? If both: clean temp folder.

Pairing is both sides. Well mostly Cpp side but 3-4 mins is extremely long..

Works like this:


Java Side:
Java side creates RandomAccessFile (Slower than shared memory and paged).
It then creates a server socket and writes the Port Number to the file at a known/static offset.
Then it listens on that port for incoming connections/commands.

Cpp side:
Reads the RandomAccessFile and creates a socket that connects to the port specified at the known/static offset.
Attempts 10 times in a loop via non-blocking socket using the "select" function rather than being asynchronous.
Once it connects, it stores the PID and TID of the thread that is using this Port. Aka Simba's Tab thread. Each tab runs a script in a thread and Smart uses that to keep track of which Thread is using which Smart.

Both:
Commands are sent over the socket and parameters written to the file.. Example.. Lets assume moveMouse is command No. 24 then:
Cpp socket sends 24 and writes (X, Y) to the files and Java server socket receives/reads that it wants to move the mouse so it reads (X, Y) from the file and then moves the mouse to (X, Y).
Both Java and Cpp sides read/write to known offsets to give and receive commands. Cpp/Simba side is controller and Java side is receiver.
Simba only communicates with the CPP side which writes the commands to a file which the Java side reads and executes and writes whether it was successful or not back to the file as a result.


What could cause 3-4 min wait time.. I have absolutely no clue but I have theories?

Paging.. Maybe your system is paging files really slow or maybe your system IO is lagging because of too many things running?
Perhaps a firewall eating up your resources and taking forever to decide whether the socket connection is safe?
Crappy net? Smart/Simba has to connect to the net first before it does any pairing/communication. If it takes too long, it times-out or just sits there and wait.. It has to download or directly load the jar.
FileIO can be slow but I've never seen 3-4 minutes unless its mega/gigabytes in size..


Iunno.. I'd have written smart with just shared memory and events or semaphores or other locking mechanisms rather than sockets and page files.. But Java doesn't support shared mem and it's quite a lot of JNI to write..

I have a class for it already written but I know for sure Ben wouldn't use it as he'd have to re-write a lot of smart.

From: Brandon
Pairing is both sides. Well mostly Cpp side but 3-4 mins is extremely long..

Works like this:


Java Side:
Java side creates RandomAccessFile (Slower than shared memory and paged).
It then creates a server socket and writes the Port Number to the file at a known/static offset.
Then it listens on that port for incoming connections/commands.

Cpp side:
Reads the RandomAccessFile and creates a socket that connects to the port specified at the known/static offset.
Attempts 10 times in a loop via non-blocking socket using the "select" function rather than being asynchronous.
Once it connects, it stores the PID and TID of the thread that is using this Port. Aka Simba's Tab thread. Each tab runs a script in a thread and Smart uses that to keep track of which Thread is using which Smart.

Both:
Commands are sent over the socket and parameters written to the file.. Example.. Lets assume moveMouse is command No. 24 then:
Cpp socket sends 24 and writes (X, Y) to the files and Java server socket receives/reads that it wants to move the mouse so it reads (X, Y) from the file and then moves the mouse to (X, Y).
Both Java and Cpp sides read/write to known offsets to give and receive commands. Cpp/Simba side is controller and Java side is receiver.
Simba only communicates with the CPP side which writes the commands to a file which the Java side reads and executes and writes whether it was successful or not back to the file as a result.


What could cause 3-4 min wait time.. I have absolutely no clue but I have theories?

Paging.. Maybe your system is paging files really slow or maybe your system IO is lagging because of too many things running?
Perhaps a firewall eating up your resources and taking forever to decide whether the socket connection is safe?
Crappy net? Smart/Simba has to connect to the net first before it does any pairing/communication. If it takes too long, it times-out or just sits there and wait.. It has to download or directly load the jar.
FileIO can be slow but I've never seen 3-4 minutes unless its mega/gigabytes in size..


Iunno.. I'd have written smart with just shared memory and events or semaphores or other locking mechanisms rather than sockets and page files.. But Java doesn't support shared mem and it's quite a lot of JNI to write..

I have a class for it already written but I know for sure Ben wouldn't use it as he'd have to re-write a lot of smart.

Would that be a possible implementation for asynchronicity (synchronicity is a word so I'm damn sure asynchronicity must be as well) since you're already doing a SMART rewrite that I *think* Ben has mentioned approval of?

From: Kevin
Would that be a possible implementation for asynchronicity (synchronicity is a word so I'm damn sure asynchronicity must be as well) since you're already doing a SMART rewrite that I *think* Ben has mentioned approval of?

Well it wouldn't make much of a difference in this case because once smart is paired, it can communicate back and forth regardless. Also it still has to wait on the Java side to create the file and map it/write to it. Getting rid of it all together would probably be the best but also the most work.. Every time we see a thread about this pairing stuff, its almost always to do with either the map file or the socket connection being refused/timing out.

It's just odd that it takes OP this long to start up.. Only saw this ever happen once before.

From: Brandon
Pairing is both sides. Well mostly Cpp side but 3-4 mins is extremely long..

Works like this:


Java Side:
Java side creates RandomAccessFile (Slower than shared memory and paged).
It then creates a server socket and writes the Port Number to the file at a known/static offset.
Then it listens on that port for incoming connections/commands.

Cpp side:
Reads the RandomAccessFile and creates a socket that connects to the port specified at the known/static offset.
Attempts 10 times in a loop via non-blocking socket using the "select" function rather than being asynchronous.
Once it connects, it stores the PID and TID of the thread that is using this Port. Aka Simba's Tab thread. Each tab runs a script in a thread and Smart uses that to keep track of which Thread is using which Smart.

Both:
Commands are sent over the socket and parameters written to the file.. Example.. Lets assume moveMouse is command No. 24 then:
Cpp socket sends 24 and writes (X, Y) to the files and Java server socket receives/reads that it wants to move the mouse so it reads (X, Y) from the file and then moves the mouse to (X, Y).
Both Java and Cpp sides read/write to known offsets to give and receive commands. Cpp/Simba side is controller and Java side is receiver.
Simba only communicates with the CPP side which writes the commands to a file which the Java side reads and executes and writes whether it was successful or not back to the file as a result.


What could cause 3-4 min wait time.. I have absolutely no clue but I have theories?

Paging.. Maybe your system is paging files really slow or maybe your system IO is lagging because of too many things running?
Perhaps a firewall eating up your resources and taking forever to decide whether the socket connection is safe?
Crappy net? Smart/Simba has to connect to the net first before it does any pairing/communication. If it takes too long, it times-out or just sits there and wait.. It has to download or directly load the jar.
FileIO can be slow but I've never seen 3-4 minutes unless its mega/gigabytes in size..


Iunno.. I'd have written smart with just shared memory and events or semaphores or other locking mechanisms rather than sockets and page files.. But Java doesn't support shared mem and it's quite a lot of JNI to write..

I have a class for it already written but I know for sure Ben wouldn't use it as he'd have to re-write a lot of smart.

Thanks for your reply. I restarted the pc and it is fine now. I did notice that when I implemented SPS-OSR into the script, this was the result. Now it's fine though :) Guess something was eating away my cpu.