Distributed Programming

[PurpleYouko]

In an access file you can have separate fields for all those things. The text file for the DNA can be split up into individual genes easily enough.
We should be able to send all this stuff in a single query.

[Numsgil]

But remember you don't necessarily need the files stored online to be readable to humans, since the only thing making queries and downlaods/uploads is the program.

Just food for thought.

[PurpleYouko]

Good point. We could easily use a detokenized code based on the the way the DNA is stored in the program. It would just need to be a stream of numbers.
The program can easily read it back into the right format.

[Numsgil]

Which is exactly what the .dbo files do.  Isn't it nice that Carlo thought ahead for us :P

[Ulciscor]

So how is this going to work? One user's program uploads the .dbo of a bot and what other info? Does the upload get overwritten when the user sends again? How are the uploads sorted? Do they expire after a time?

[PurpleYouko]

The uploads should stay on the server until they are downloaded again, then they get removed.

The old way just wrote the DBO files directly to a folder on the server PC then went in and chose a random file to download. After that it would wipe the file that it downloaded.

The database method should work the same way.

The server should end up being a repository of hundreds of DBO files at a time. Downloads and uploads are random

The old way was really slow. I would like to see all the clients physically logged into the database whenever a sim is run with internet sharing enabled. Uploads and downloads would then be pretty much instantaneous so true multi-player sims may become possible.

Even better if we have different "channels" that can be selected in the DB program. These would point to different tables in the database.

[Numsgil]

That's pretty much what I'm thinking.

I'm not sure that a 100% upload->download0>delete cycle is best, since users can download some organisms and then just turn off their computer.

I can see some griefers messing with several weeks worth of work.

So maybe periodic saves are produced which can only be downloaded, that contain all the bots on the database at a specific time.

[PurpleYouko]

or another way to work it is that a client uploads 1 then is only allowed to download 1 if more than a certain number (say 100 or more) are present on the server.

We can also require that an upload happens before a download/deletion is able to occur.

A further option is instead of full deletion of the database entry, it could be transferred to a shadow database like the deleted messages in Outlook. That way a strain won't be lost forever if someone does as you say and turns off after taking the last one.

Anyone with a copy of Outlook or even Excel can set up a "copy" link to the database and read files out of it at any time. We just restrict writing and deleting to in-game activity.

[Ulciscor]

Hmm this might get awkward.

[PurpleYouko]

Why might that be pray tell?

I do this kind of stuff with SQL servers at work all the time. Just never tried doing it over an internet connection.  :wacko:

[Numsgil]

Would also like to point out the other sort of griefing:

Suppose you're trying to evolve a specific bot.  Say animal minimalis.  And some jerk/newbie unleashes One (with mutations disabled mind you) into the database.

Doesn't take a genius to figure out what's going to happen.

Worse, what if some jerk copies One's DNA into a file called Animal Minimalis?  Then the program can't even do a quick check to determine if the fname is right.

I see periodic (say, daily) backups as the best solution.  If something goes wrong, then everyone just reverts to the backup.

I dunno, there are some problems there too.  It's sort of a huge population crash...

If anyone has any ideas for this, that would be swell.

[Botsareus]

Well if you are doing a Distributed Project, don't the starters select the users who would join them. Don't the exsisting users modulate new users?

[PurpleYouko]

We aren't talking about a distributed project.

We are talking about run-of-the-mill Darwinbots programs uploading/downloading organisms to a centralized database.

Anybody who downloads and runs DarwinBots would by default have access to this feature in the software.

[PurpleYouko]

We had that kind of trouble way back when I discovered tie feeding was possible in V2.1

I published the first version of Devincio Venator to the forum with a warning that he was highly prone to crashing the program by tie-feeding more than 5000 energy per turn (this has since been severely capped)

Within a few days I began to recieve my robot from the server with somebody elses name on it.

As you say Num, some asshole is likely to take an innocuous name and fill it full of the deadliest DNA possible.

Possibly the client program can have built in filters added which will clearly label different types of bot before uploading them, then we can allow downloads to be filtered for these labels to prevent bringing something like "The One" into a delicate eco-system.

There are certain bits of DNA code that are easily recognizable by the program so they could be automatically labelled this way.
Another possibility is to keep a constant efficiency rating with each bot file. A kind of profile based on highest feed rate, energy expenditure rate and so on. Then we send this label with it to the database.

[Numsgil]

Perhaps what we need is a sort of metric:

Some function assigns a value for the distance between two robots' DNA.  Distance functions only have to fulfill the following:

distance of A to B is distance of B to A
distance from A to A is 0
distane from A to C is <= distance from A to B + distance from B to C

So it doesn't have to really do anything at all with how we normally think of distance.  It's just a measure of the difference between two DNAs.

Then users set that they only want to download bots that are within a certain "distance" from some start bot, that is, within the "neighborhood" of some start bot.

The smaller the neighborhood, the less you're allowing dramatically different bots into your simulation, but the less likely you are to get some incredibly amazing bot who's DNA is dramatically different from its ancestor.

Perhaps the neighborhood applies to the most populous bot in your simulation.  Or maybe it applies to the mean of the bots' DNA's.  Then you're just excluding incredibly unlikely major "jumps" in a bot's DNA.

I'd just have to think of how to construct such a metric.  Preferably it'd have the distance between two DNAs be very little when, say, the DNA of one is just rearranged compared to the distance of the other.