Status of IM mode

[Ammeh]

So I had a play with IM mode, and got largely nowhere. It looks like the server side code isn't working (or missing?). I don't particularly want to completely rewrite it, seeing as how Shasta did a pretty nice job of the memory hooks and the whole stat thing was already in place. Repair seems like the best option.

So, what's the deal?

[Shasta]

So from what I remember I broke one of the php scripts at some point. They are definitely not being served at the moment, though I do still have them in a folder.

The C# program is a bit annoying as it does the memory inspection stuff, so you have to give it a new list of memory locations for every new version of DB released, I had some sort of update mechanism that I don't entirely remember at some point. But finding the memory addresses was manual. If someone wants to work on it, I'd recommend just removing the memory inspection and only handle the transfer of robots. A technical detail: I think it was using LZMA compression, switching that to something like LZ4 would be nice.

[Botsareus]

Hey Shasta,

May I look at the PHP script(s) if you don't mind?
Just out of curiosity.

[Ammeh]

So really, we could do with a way of getting DB data without memory hooks. Botsareus?

Named pipes seem like a possible, could make it pretty flexible and just have DB dump json down the pipe, have the DBIM app upload the json data along with bots from files. Script server side processes JSON into DB, handles file allocations etc.

[Botsareus]

Ns what you mean by memory hooks.
If you mean DB has to communicate with IM, yes we can get rid of that.
The only thing we need to pass to IM is the folder paths to the inbound and outbound folder. This is being done already as part of the command line pass. IM then simply writes and reads from these folders and DB takes care of the rest.


It sound to me like you want to code IM as part of the vb6 source? That is reasonably cool, except for the fact the vb6 is almost a dead as a computer programming language.

p.s.

Thank you,
I still want to see the code when it is done 

[Ammeh]

Nah, I'd keep it seperate from the core code, but have DB build a named pipe (https://en.wikipedia.org/wiki/Named_pipe), which DBIM could latch on to. This would basically mean that DB and DBIM would be compatible regardless of updates to DB.

Of course, if we were getting rid of the whole stat thing, then simple file up/download would do. I could probably knock that together in a couple of hours.

[Botsareus]

Well, the IM status graphs are no longer available inside DB as of 2.45.02. (I wanted to make communication with IM more simple)
You can generate them externally if you like, maybe a php/java script?

[Ammeh]

IIRC, the only stats read by DBIM were the population, cycles per second, size and mutation rate, and I'm pretty sure all they did was feed into the IRC bot.

[Botsareus]

Oh, so nothing is being read from IM back into DB?

the only stats read by DBIM were the population, cycles per second, size and mutation rate

Hmmm, Idk if I touched that code or not. I can not even find it in 2.45.01, do you have any idea where to look?

Or, we can just get rid of this and make IM just keep track of # users and # bots transferred per (minute?) and post to a web page.

What do you think?

[Numsgil]

the only stats read by DBIM were the population, cycles per second, size and mutation rate

Hmmm, Idk if I touched that code or not. I can not even find it in 2.45.01, do you have any idea where to look?

It was an external application that would read raw bytes inside Darwinbots at specific memory locations.  The program had no idea what was going on.

[Botsareus]

It was an external application that would read raw bytes inside Darwinbots at specific memory locations.

wow, that is intense.

[Botsareus]

Maybe we can make DB write this data into a file periodically. But honestly I don't think we need something this advanced.

[Ammeh]

Well, this is what I was talking about with pipes. Pipes are basically sockets (like network connections) between applications running on a machine, and you can send and recieve data through them. I was thinking if DB sent it's stats in JSON format like so:

Code: [Select]

{ "population":"12381412", "cyclespersec":"50"}
down the pipe, then DBIM could just send that straight up to the server, which would process it server side. What this means is that we can make one modification to DB (adding pipe support + json), create a new DBIM and server script and then have all the functionality we currently have with the caveats that:
a) We wouldn't need to update DBIM ever again (unless a bug appeared or another overhaul was needed)
b) Adding new stats to track would be a simple case of adding the stat in DB's JSON sending bit and updating the server script to process the new stat, instead of an update to all three elements (DB, DBIM, server script)

Also, this potentially allows for complete control of the DBIM application from DB's interface if we want to go down that route.

[rwill128]

This is so exciting to hear people talking about getting Internet mode active again.

It seems like the chances of really cool evolutionary dynamics/occurrences are going to be much, much higher if we can get a lot of people contributing to a larger simulation.

[Botsareus]

I think I get it.

Go ahead and do that, just label your SVN Commit (source code) with your username for vb6, so I know it is you.

thx

edit: should be under Darwinbots2/trunk/Darwinbots2