AutoHotkey Community

[elektron]

Alright, so my first adventure into this was with java, but as of last month I found myself having to somehow convert thousands of FLAC files into MP3's in a reasonable bit of time. My solution ended up being autohotkey after condor didn't work right for me. (I hate condor)

So, I developed this one autohotkey script, used windows live foldershare and transferred it to all the computers around the network, then synchronized each of their computers with a associated folder on the server.

The script that I wrote used FLAC.exe and LAME.exe to convert the files, delete them, then listen for more flac files. The only issue with this was that I was relying on an external program in order to transfer the files intranetwork. It's not that complicated of a process, I wrote the script in 2 hours, including debugging.

So my question after the fact, was how I could integrate this into it's own self-reliant distributed computing application, much like condor, but not as stupid. Condor is simply difficult and bulky to use, and doesn't give that much of a analysis as to what it's doing.

Unfortunately I don't have the sources on me for the application that I wrote, not at this moment anyways. I will post them later if anybody is interested in this.

The design philosophy that I want to follow is very concise. I think everyone will agree with me when I say that there needs to be a decentralized, agreeable, simple, and statistically efficient way to manage a distributed computing application.

Main Objectives:
1. The program should be Free.
2. The program should be Reliable
3. The program should be Simple.
4. The program should be extensible.
5. The program should be scalable.
6. The program should function across NAT, WAN.
7. The program should be easily configurable.

So my idea is mainly to utilize a set of programs to accomplish the task needed. It will require autohotkey experience, but not much. The concept pretty much follows my initial application, with the exception that instead of listening and acting on the FLAC files, it acts on the EXE's requested. However, I do not wish to use Windows live sync for any of the transfers, so the program that is acting on these EXE's is going to need to listen for transfers, submit transfers, and act on logging and such as well.

So it pretty much breaks down like this:
1. Dist.exe
Listens on a socket for file transfers such as job directives.
Listens for EXE directive (coded in AHK)
Acts on the EXE directive.
Submits back to the server.
Listens for a new directive when finished.
Submits Logs
2. Job.exe
This is the "Job File" that dist is going to act on.
3. Config.exe
Configures ini's that dist.exe and Job.exe will use.
This needs to be graphical.

As the job file goes, I was thinking about usings some sort of iexpress or something like that as a job file setup, that way it is easier to include media, inf directives, and stuff like that all into one job, and have every computer act on that. The bad thing about this is that the files need to be compiled and setup to be a certain way for each machine, but there's no way around that from what I know.

It could be possible to use http to transfer the files back and forth, but I'm not sure how well that is going to be coordinated. It'll have to use odd ports for sure, and be configurable at the very least.

On another note, I think that once everything gets sorted out, it would be really really cool to have plugins and such, for things like wordlist generation, rainbowtables, ftp uploads, processing tasks, conversion tasks and such, just so the user can easily create directives without getting too much into the code.

This is a really big project that I want to start up, but I'm going to need a lot of help with the sockets and such, especially since this is going to possibly used for gigs and gigs of transactions. At the moment it's not totally necessary to have it go beyond LAN, but it would be advantageous to have in the future.

For the file transfers to work, think more or less RSYNC or something like that.


Tell me what you guys think; this concept has great potential to go very very far. Not only is it conceptually badass, but it's even cooler this will be coded almost entirely in autohotkey. That alone is a hack to be reckoned with.

Wish to hear from you all soon,

-- elektron

[elektron]

Bump?