So, how would YOU design a DC project

[rsbriggs]

FoBot mentioned that one of his requirements for "the perfect" DC project would be personal proxies. I suspect that "prevention of cheating" might have to figure into doing that.

So, what would people here recommend as a "perfect" DC project design? It would have to factor in both user convenience and project security - preventing an unscrupulous user from taking whatever source code or design information is made public, and using it to return faked results. Are the "crunch engines" open source, and the client server protocols kept closed? Open protocols, but closed crunch engines? Open both? How about result-validation and project security?

As for me, one requirement would be "nearly instant" stats - updated team and user standings available frequently, certainly more often than once per day, and real-time updates would be best of all.....

[FoBoT]

small memory footprint, ok that just really depends on the type of data being processed i'm sure

um, how about:

multiple OS support

ability to run it offline

for winders clients, native service support

not too big of chunks. what that means is, for example: with the current stuff from SoB , you get a number (or whatever the "k" / "n" thing means :scratch: ) to check for a prime (or whatever it does, ok so i am not the most scientifically literate DC'er around :o ) . it takes about 1 week or more to do the work before you get credit (even if you turn in intermediate blocks, you lose all that "intermediate" credit if the work is never completed). i have lost work , in the case of SoB , many days worth of work on SoB due to this GIANT chunk of work size issue / thingy. does that make sense ?

free cash to everybody that helps! :harhar:

[Darkness Productions]

Personal Proxies:
[list=1]
These must be able to provide a "pass-through" situation for returning work.
They should also handle client upgrades (in the way that the DF "proxy" does).
I should be able to retrieve stats from said proxy (last upload time of a client, etc).
[/list=1]

Stats:
[list=1]
Only the simplest stats should be provided by the project (an XML file, or a gzipped tarball) so that the bandwidth burden could be offloaded to 3rd parties.
Teams should be supported, and switching teams causes your work to stay with the team.
[/list=1]

Client:
[list=1]
Easy setup. You plug in an email address (or client ID), and off you go.
Configuration options by a .rc file, or .ini file, which would restart on a change of this file. File should include all proxy settings, username settings, etc. It should *NOT*, I repease *NOT*, require a team name, nor should they be case sensitive.
The client itself should need little to no attention on the part of the user, and should be highly configurable (% processor usage, hours/minutes processing time per day, etc).
It should have built-in benchmarking of whatever the client is supposed to be doing.
Seperate "cores", like in the dnet project, would be nice, but not required (however, if they exist, they should each be optimized for a processor. I know that this creates extra maintenance work on the part of the project admins, but gets them extra work done as well).
The client should be closed source, but openable via NDA (Non-Disclosure Agreement).
It should run on multiple OSs (Windows, Linux, Solaris, Tru64, etc).
Running without the need for external applications (anyone tried installing Java on an Alpha Linux box lately?) would be great.
Native service install. For windows, this means an actual service installer. For *nix, it means adding the appropriate entries in /etc[/rc.d]/init.d, etc
Logging support. All entries made in the logfile should be timestamped (preferably with the correct locale timezone, but GMT/UTC would be fine for me).
Logging support from above should be customizable. There should be several levels to choose from, from "All" to "Critical/Severe", and many in between. This allows for debugging messages from the client, as well as actual pertinent error messages.
Small network footprint. I shouldn't have to upload 15M at a time to return a WU.
Small client download. Just an executable, maybe even the .rc/.ini file. Make the executable create the files it needs when it downloads data from the server (if it needs to. If it doesn't, then just create the files at run-time).
As much as Larry Loen hates this, support for multiple processors is A Good Thing (TM) in my book. I don't want to have to setup multiple copies of a client (which causes possible errors to occur) just to run it on a machine. Spawn off another thread, and be done with it.
"Stateful" client checking. A .lock file is nice, but don't rely on that to know if the client is running or not. Every OS has tools to find out if a process is running. Use them.
If no-netting is allowed, then don't cause the client to die on upload if the .lock file (or another process) already exist. This way, you upload, but keep right on chugging along.
Individual machine IDs are nice, as they allow you to see (from the stats page, or elsewhere) when the last time your Aunt Ethel connected her machine and uploaded.
Connection checking. The d.net client is the only one that I know of that does this, but checking if there's an internet connection, and uploading in the background is Another Good Thing (TM).
[/list=1]
I'll come back to this section later if I think of anything else.


Main Server:
[list=1]
Should be able to handle a massive number of simultaneous connections (10-30? I guess it depends on the size of the project).
[/list=1]
Other items may be added at a later date.

Project Admins:
[list=1]
Should be easily reachable by the project users.
[/list=1]

Can you tell that I've been stewing over this kinda stuff for a while?

[FoBoT]

:D nice list DP , you sure you didn't just pull that out of ... nevermind :mouserun:

my favorites from your client list - 13,15,17 :)

[Supp]

Project should do some real science - not nagging crypto projects now, but
remember NeoPrj (##$?!?@:swear: ) and for example Ubero (repeating same WUs for better part of year...)

[rsbriggs]

Stats:
Teams should be supported, and switching teams causes your work to stay with the team.

This REALLY doesn't seem very difficult. Teams are composed of a simple list of members and the number of points those members crunched while part of the team. Members consist of name/identifier, total points crunched, current team affiliiation, and the number of points crunched for that team. When a member changes teams, he just goes from active to inactive on the old team, is added or has status changed from inactive to active on the new team. If he ever switches back to a team that he was previously a member of, his "crunched for that team" points get set to whatever they were when he was last a member. Each upload, both his overall total and the total-for-current-team numbers get updated.

/me wonders why so many projects find this so difficult to implement???????

[rsbriggs]

Project should do some real science - not nagging crypto projects now, but
remember NeoPrj In all fairness, I really think that the NeoProject was valid - an attempt to break the 2048 bit encryption key of the xBox. The way that it is being done - well, I have some issues with that.... First off, they have summarily discarded most of the key space, and are only checking 309 digit numbers, this follows from their assumption that the two keys are of equal length. But, claiming to have disk space issues, they don't keep track of the blocks of keys checked, nor do they assign blocks to be checked. Work units are generated locally, randomly.

And I think that Klingon_Programmer showed everyone how easy it is to cheat your way to trillions of keys checked and make one upload and be at the top of the stats. Even GIMPS, SETI, and other, better organized projects have had problems with cheaters.

The last I knew, they (neo) were also doing some slightly more valid DC projects, like attempting to find a better solution to the all-cities-travelling-salesman problem, which is not a trivial task Haven't checked on them for a long time now.....

They point out one problem with making source code available - cheating. Heck, if you think about it for 30 seconds, you realize that it's incredibly easy to cheat at DF, if only until what is going on gets recognized for what it is. I'm certain that I could easily have the #1 Free-DC DF crunching spot, if I was at all interested in cheating....

[IronBits]

Originally posted by FoBoT
:D nice list DP , you sure you didn't just pull that out of ... nevermind :mouserun:

my favorites from your client list - 13,15,17 :) Maybe Howard should hire him! :thumbs:
He gets my vote :D

[rshepard]

/me wonder why so many projects find this so difficult to implement???????

It isn't hard to implement-but it is hard (impossible) to get everyone to agree that it should be done that way. For every person who says "the points belong to the team", you can find someone who says" the points belong to me"-- ultimately all a project manager can do is decide what s/he thinks is right, say "this is how it is", and then let the users decide if they want to participate under those rules :dunno:

( personally, I fall into the "these are my points camp", for whatever that's worth)

[rsbriggs]

I think that it could easily be argued either way. It's just something the project has to set down in advance.

But while I agree that individual points belong to the member (his total points are always going to be his in the individual standings), it is easy to argue that allowing a user to "take his team points with him" is unfair to the teams and all members of the affected team.

Imagine what would happen to the FreeDC team if IB and PCZ suddenly decided they wanted to go off and form the We-Don't-Like-FreeDC-Anymore team, or if Bguinto1 suddenly decided to switch to a team other than ARS. I don't think that it's fair that a single defection can completely destabilize or destroy a teams standing, and probably the moral of everyone that has contributed to the team.

So, that would be my argument for believing that an individuals stats are his own, on an individual standing basis. If he crunches a bazillion poings, and goes to the top of the list, great! But if one joins a team, then one is allowing them to share in the benefit of the points crunched while a member, nothing more. Changing teams doesn't affect that individuals personal standing, nor does it immediately and adversely affect the team that he leaves, nor confer a enormous benefit to the team that he joins. He now has to get in there and show his worth to the team, starting from the bottom and working his way up, JUST LIKE EVERYONE ELSE ON THE TEAM DID INITIALLY. IMHO I think it makes for better team play and a longer term point of view on everyones part..

[IronBits]

/me passes around a collection plate :D :gone:

[FoBoT]

Originally posted by rsbriggs
[b]/me wonders why so many projects find this so difficult to implement???????

i don't think that they find it difficult, most don't even think about it/know its an issue, until its too late

for others its a conscience decision, there are two camps on this, those that feel the credit belongs to the individual to take with them if they move teams and those that feel the work belongs to the team it was crunched under at the time it was done

if i am not mistaken, most of the BIG projects never thought about it up front and it just turned out the way it is

personally, i don't really care which way they go (as long as in the overall individual standings your total work amongst all teams can be accessed) as long as they make it clear up front and DON'T change it after the horses are out of the gate

[rsbriggs]

/me passes around a collection plate

If you mean me, IB, I'd be glad to be doing some nice Unix (saying that isn't some sort of SCO copyright violation, is it?) programming. For money. To keep the electricity meter going to power the computers that do the DF thing....... :crazy:

[IronBits]

Originally posted by rsbriggs
If you mean me, IB, I'd be glad to be doing some nice Unix (saying that isn't some sort of SCO copyright violation, is it?) programming. For money. To keep the electricity meter going to power the computers that do the DF thing....... :crazy: erm, no... I was joking :D <--- (points, hostage, nm)

I was wondering tho...
How much power I could get back by hooking up something to that damn wheel inside that glass dome they call a meter, to drive a generator? :scratch:

[rshepard]

Imagine what would happen to the FreeDC team if IB and PCZ suddenly decided they wanted to go off and form the We-Don't-Like-FreeDC-Anymore team

Flip that around-- imagine what would happen if everyone but me left Free-DC, but their points stayed? Am I still entitled to whatever prestige is attached to being the #1 or #2 team, even though I'm the only one left?
I think this whole issue brings up the question of what a team is. If it exists solely as a collaboration of individuals, then I think the individual's contribution rests with the individual.
If it exists without the individuals that make it up, then the argument that the team "owns" the contribution may have some merit.
The philosophical waters get deep out here...


/me decides its time for another :cheers:

[rsbriggs]

Flip that around-- imagine what would happen if everyone but me left Free-DC, but their points stayed? Am I still entitled to whatever prestige is attached to being the #1 or #2 team, even though I'm the only one left?

Yes. You'd certainly be entitled to whatever prestige you can hold on to, for as long as you can hold on to it. You are still part of (maybe the last remaining member) that team.

The reality is, the next hours update is going to see the other teams eat your lunch. Live your one hour of glory!!!! (If anyone even notices...)

(But, why are YOU still there when everyone else has bailed?)

Ask yourself this question, too. Suppose everyone except Bguint01 bailed out of ARS, and he was able to hold the teams position where it is by himself. Would he be worthy of the prestige? In my book, Absolutely yes.

And, reality check... What is the probability of any of this actually happening? You can build hypothetical cases that serve as a counter-example to any real world situation. There is always a "what if" that breaks something, no matter how low the probablility actually is. Most programs get broken by the "but what if an asteroid hit the planet and killed everything on it, so that no-one could hit a key?" scenario.
(Then the fact that a tape backup didn't complete successfully in that case really wouldn't matter, anyway, would it?)

Is it fair to the other teams, and everyone who has been crunching for them, that LemonSq, Bguinto, IB and PCZ could decide to form a new team, and instantly have the number 1 spot, with no other team able to touch them? Even teams that have been pouring their hearts into doing DF for a year? Poof. Everyone is just SOL?

Nahh - that just doesn't seem fair to me....

[rshepard]

And, reality check... What is the probability of any of this actually happening?

granted-- arguing from an absurdity is questionable at best. Sorry....



Is it fair to the other teams, and everyone who has been crunching for them

breaks into two points:
YES, it is fair to the other teams- they are free to step up recruiting, or try to recruit away one or more of the "heavies". You may as well question if it is "fair" that we and ARS lead all other teams by a 3-to-1 margin or more. I'm not sure that fair is a quality that should be applied to teams in any case.

YES, it is fair to everyone who has been crunching for them, because they are (a) free to join the new top team, if that is important to them, and (b) they still have their individual rankings, if that is what is important to them.

Maybe I spent too much time crunching as an independant.... I feel like I'm missing out on something here.

[rshepard]

I can tell I've been online too long when my browser suddenly grabs 80% of the CPU and hangs. Some last comments and then I'm off to bed:

1. Apologies if this debate hijacked this thread-- was not my intention-- I can be a wordy SOB once you get me started:blush:

2. This is like debating politics or religion-- sooner or later you end up with views that are 180 degrees apart, and there is no resolving it.

3. In the end, it doesn't matter which side you pick, or who you crunch for, or which project you crunch for; as long as you are keeping the 1st Commandment of the DCer's Bible:
"Thou shalt not let cycles go to waste"

/me signing off 'til tomorrow :thumbs:

[Dyyryath]

Threads like this are interesting. Over the years since I started with DC, I've formed some pretty solid opinions on how things should and should not be done. Of course, I also tend to look at things like the various project clients and think I could do it better (though the reality may be somewhat different). That is, in fact, what got me started doing stats. ;)

I've wished on many occasions that I could convince Howard to give me the source for their client. I'm not even remotely interested in the way it does the actual 'work', but I sure would like to take a crack at the way it uploads/downloads, updates, and logs...

[FoBoT]

the "points are the teams" vs. "points are the individuals" debate is almost as old as IB, i mean dirt, i mean... :blush:

[rsbriggs]

Well, I guess that my entire motivation for starting the thread was to see just how much interest there would be in playing a little game - doing a simplistic open-source DC server, client, and proxy server. Then evolving that into something that could hand out simulated work units, track teams, keep scores, do stats. Given the programming talent we have here, and the overall interest in doing DC work, we should be able to come up with something, and it could be a nice "learning experience" for everyone involved....

First question is, naturally, what OS does the SERVER run on. Which of course leads to additional questions. Who knows where it might take some of us. Learning PHP? HTML? XML? 'C'? Java? Database design?

If the proxies are going to have to "mostly duplicate" the server functions, they are going to want to/need to run on multiple platforms, which makes it harder to settle on an OS for the server....

Does that mean using Cygwin, or something equivalent? Does that limit things to strictly Linux and Windows?

Comments, questions, suggestions????

[Darkness Productions]

I don't (personally) see why it makes it harder to settle on an OS for the server. The main servers functionality would be fairly straightforward. It accepts connections. That's an over-simplification, and I'll expand on it shorltly.

The proxies main functionality is to pass-through the client requests to the server. It might have some checking to see if the server is up instead of just blindly connecting. The proxies should be able to run on any major OS (Windows, Linux, BSD, Solaris, Mac OS (*), etc).

Back to the server. To expand a little on what I said, the server accepts connections. Some of the connections that it's looking for are new user requests. Personally, I dislike the projects where I have to signup on the webpage, then start the client. I should just be able to download the client, plug in my email address, and the client connects to the server, checks if I'm a new/existing user, and goes from there. It might be cool (if I'm a new user), if the client (after receiving confirmation of this fact from the server) would prompt me for my preferred Username, my location, etc etc etc. The server should also handle the passing out of WU and the retrieval of WU. I think that's pretty much all the server needs to do from the connection side. The only other thing it should do is shove the results in a database somewhere for checking/verification at some later date.

Any other thoughts?

[Dyyryath]

OK, this sounds like an interesting idea: build a distributed computing project...for fun. I like it. :D

I'd suggest that before we get into making any decisions about operating systems or languages that we first decide what kind of work it's going to do. It doesn't have to do *real* work, but we will need something to use a 'work unit' and something for the client to do.

Since we don't want the 'client' stealing any cycles from our real DC clients, I'd suggest putting it in a sleep cycle based on the processor speed of the machine it's running on. For example, we'd say the base sleep time is 4 hours (240 minutes). Then for every 100 mhz over 1500 that the machine's processor has, it'd subtract 4 minutes from the sleep time. For every 100mhz below 1500 that the machines processor has, it'd add 4 minutes to the sleep time.

To use an example:

A 1500mhz processor would 'complete a WU' in 4 hours.

A 3200mhz processor would 'complete a WU' in 2 hours, 52 minutes.
(3200-1500 = 1700mhz / 100 = 17 * 4 = 68, 240 minutes - 68 minutes = 172 minutes)

An 800mhz processor would 'complete a WU' in 4 hours, 28 minutes.
(1500-800 = 700mhz / 100 = 7 * 4 = 28, 240 minutes + 28 minutes = 268 minutes)

At the end of each sleep cycle, we'll need the client to come up with something to send back to the 'project'. Perhaps a series of MD5 hashes or something?

If we wanted to use the "download work, upload work" routine (rather than the DF way of just uploading things), we could have the client download a small block of text as a pretend WU, then return an MD5 of that text at the end of the sleep cycle. This would also let us experiment with WU caching by proxies, for both uploads & downloads.

After we got 'Phase 1' or our client working, we could experiment with 'client updates' by sending changes to the timing routine from the 'project'.

[Dyyryath]

Heh, I'm back from my daily meetings with more thoughts. ;)

Once we've determined what we'll use as a 'work unit', we can start figuring out how the server will be setup. I'd guess that we could easily use any modern OS, but I'll suggest Linux for two reasons:

(1) Development tools are built in
(2) It's free

This could also be expanded to cover the database we'll put our results in. MySQL is fast and capable (despite what Larry Ellison would have you believe ;)). It's also free. One of the biggest hurdles that these projects seem to encounter is funding. The less we spend on software & development tools, the more we can spend on hardware & bandwidth.

So, if it were me, we'd have decided:

(1) Clients accept a work unit payload for processing. For our purposes, we'll use small pieces of text.
(2) The client sleeps for a specific period of time based on processor speed to simulate the processing of our work unit.
(3) The client wakes up, creates an MD5 of the text to simulate the processed data, and uploads it to the server in return for another work unit.

The next step, in my mind, would be to determine how we will track work units, users & clients. Do we want to track clients (machines)? I'd say yes. As a user, I'd love to be able to see stats based on each machine in my farm.

Given that, what do we need to know about each to track them?

For the user, I'd say (at a bare minimum):

(1) A unique numerical user id, generated by us when they begin crunching/register
(2) A username for them to track themselves with in the stats. Do we want this to be unique?
(3) An email address to reach them if it became necessary
(4) A password to allow them to ensure they are the only ones sending work under their name/id, and to make changes to their settings
(5) The id of the team the user belongs to

For the client, I'd say:

(1) Unique numerical client id, generated by us when it first receives work
(2) The id of the user it belongs to
(3) A machine name to allow the client to easily track it within the stats

For the work units, I'd say:

(1) Unique alphanumerical (gives us more range with fewer digits) unit id, generated by us when a unit is handed out for processing
(2) Client id of the machine it's been processed by when it's been returned
(3) Team id of the team it was processed for when it's been returned (if we want work to remain with teams, otherwise we could leave this off)

Have I missed anything we'd need to know about any of these things?

[rsbriggs]

This could also be expanded to cover the database we'll put our results in. MySQL is fast and capable (despite what Larry Ellison would have you believe ). It's also free. One of the biggest hurdles that these projects seem to encounter is funding. The less we spend on software & development tools, the more we can spend on hardware & bandwidth. I certainly agree there, I've used MySQL for more "embedded" applications that you can imagine, ( erm, but only via the 'C' interface.) I think it would be foolish to use anything other than Linux/Apache/MySql types of tools....

Don't know squat about PHP, which seems to be the big buzzword these days. Can PHP do MySQL, or can MySQL do PHP, or whatever the appropriate terminology would be? Have a dozen other responses/questions, but am caught in a crunch at work. Will be here until late....

One last quick comment - I agree and don't think .lock files should form the client/core interface mechanism. Core should be able to wake up from time to time and tell the client how things are going. Client should be able to check from time to time to see how things are going with the core from the other direction. Both should be able to tell the state of the other and communicate things back and forth like shut down messages, % complete, etc.....

edit:

Back again. Given the correct client/core API, it should -theoretically- be possible to drop something like a DF core into things and have it just work. This is where things get a little complicated - IPC mechanisms kind of vary from OS to OS...

[IronBits]

This sounds like FUN :D
I wanna play! :cry:
I can offer a *nix and w2k boxen to run the client on ;)

Maybe this could be a 'shell' thing to run the real DF client under :thumbs: :scratch:

[Dyyryath]

Don't know squat about PHP, which seems to be the big buzzword these days. Can PHP do MySQL, or can MySQL do PHP, or whatever the appropriate terminology would be? Have a dozen other responses/questions, but am caught in a crunch at work. Will be here until late....

PHP & MySQL get along wonderfully. It is, in fact, the entire basis for the site I'm responsible for at work (http://www.fayettevillenc.com). Everything on that site is dynamic and generated from a series of MySQL databases. It's all coded in PHP (aside from a few specialized Perl scripts I wrote to handle user registrations & specific search types).

As a Unix guy, I like the idea of specialized, discreet tools working in harmony rather than one big tool trying to do many things. This could be applied to the design of the client. Basically, it needs to do several things:

(1) Process the work units
(2) Upload & download completed work units
(3) Handle updates to it's own codebase
(4) Provide varying amounts of feedback on it's status to the user
(5) Manage it's use of resources and it's place on the system

When I look at this, I see two distinct pieces:

(1) The 'core' which does the actual processing
(2) The 'framework' which handles everything else

As a programmer, anytime I see two different things that need to communicate, I see the need for an API. If you have a good API, you can change the two things that need to communicate independently of each other without causing any problems.

For rapid development, I'd probably build a shell in a high (higher than C ;)) level language, and then build the core in C/C++ or assembly to ensure maximum performance. The cool thing about this is that you could theoretically build your shell or framework code in the language that most suits the target system. For any Unix, I'd probably use Perl or another interpreted language (though Perl is pretty much available on all Unixes unlike some of the newer ones like Python).

Perl could probably work for Windows as well, but you don't want the end user to have to install a language just to make something run. Perl is easily compiled for Windows, but the filesize would probably be larger than necessary.

Under Windows, Visual C/C++ or even Visual Basic might be a better choice. In the end, you could probably break all your client targets down into two groups: Windows & "Not Windows", leaving you only two "shell" frameworks to deal with. VB or VC should both run fine on any version of Windows, and because it's interpreted, Perl (if properly written) would run without modification on pretty much any Unix (i.e Linux, *BSD, Solaris, Mac OS X).

When a user downloaded the client, they'd just get the small 'framework' code which would handle getting the correct 'core' for the architecture it was running on, setup the user's account with the server, and then download the work unit & begin crunching. It'd even be easy to build functionality similar to what dfGUI provides into it. Rather than relying on a progress file, though, it could simply query the core directly through it's API and display the results in either an easily viewed text file or through a more advanced GUI, depending on the user's preference.

[IronBits]

OSI 7 layer GOSIP stack (or something like that)? ;)
Alright, now we are gonna have our very own project to?!?!?!?! :elephant:

[rsbriggs]

Maybe this could be a 'shell' thing to run the real DF client under/me thinks there are a few technical obstacles in the way of doing that currently. Not that it wouldn't be possible to write a DF core that WOULD work. Hmm - DF scoring might present a challenge....


OSI 7 layer GOSIP stack (or something like that)?Any network protocol with 7 layers has 2 too many of them. :D Nahh - the API would be rather more simple than trying to implement the entire OSI networking model.......

[rsbriggs]

When I look at this, I see two distinct pieces:

(1) The 'core' which does the actual processing
(2) The 'framework' which handles everything else

As a programmer, anytime I see two different things that need to communicate, I see the need for an API. If you have a good API, you can change the two things that need to communicate independently of each other without causing any problems. KaaChing! Bingo !! Dyy - it isn't hard to tell that you've done a little development, too.... :D :thumbs:

[Darkness Productions]

Originally posted by Dyyryath
Perl could probably work for Windows as well, but you don't want the end user to have to install a language just to make something run. Perl is easily compiled for Windows, but the filesize would probably be larger than necessary.


While this is true, if all the user is downloading (upfront) is the framework, then you could probably get your framework in under 1-2M (absolute tops), compiled. That would make it really easy for new coding, but does it give us access to everything that we'd like to possibly have built-in? By that, I mean things like stopping on battery (something I love about the dnet client), checking if we have a connection out (again, something I love about the dnet client), etc.

Under linux, these things would be fairly easy, even with perl. But under Windows, that may be a bigger challenge, as I don't know that Windows keeps track of that stuff in any easy way that we could get to.

But then, I could be wrong ;)

[excaliber]

Sorry to revive this old thread.

I'd just like to say that PHP is fully capable of just about anything, including the actual server code. Despite the pseudo-failure of my project, the server (PHP) code worked amazingly well, and made real-time stats on the website a snap.

Thats all I wanted to say :)

[Darkness Productions]

Has anyone thought anymore about this? Every once in a while, I get a wild hair and want to start working on this, but then run out of time. If I can find some spare time on the weekends, I'll start working something up that we can use and go from there.

[Darkness Productions]

Ok. I made some time earlier, and have started working on the main client portion (the one that figures out how long the result should take to generate). My next step is creating the server, and going from there. Anyone have questions/comments?

I'd happily post the code if anyone wanted to see it.

[Starfish]

Hi! Very interesting thread!

I must confess I haven't read all the details (yet, also learning an exam about AI at the moment :D ) , but I see things about development being mentioned, including Perl and PHP.

I'd like to throw in another suggestion:

(hope it's not to late!)

Python (http://www.python.org)

I've just started learning it, but I'm quite impressed by things like its clarity, speed of development, etc.

Points from the website:

- it runs on many brands of UNIX, on Windows, OS/2, Mac, Amiga, and many other platforms

- combines remarkable power with very clear syntax

- It has modules, classes, exceptions, very high level dynamic data types, and dynamic typing

- interfaces to many system calls and libraries, as well as to various windowing systems (X11, Motif, Tk, Mac, MFC)

- New built-in modules are easily written in C or C++.

Accessing MySQL is also not a problem using the MySQLdb module that can be found on sourceforge.


Regards,
Starfish

P.S. Is is obvious I've somewhat fallen in love with this "Exceptionally Clever Snake" that is like "Snake Oil For The Soul " ;)

http://www.devshed.com/Server_Side/Python