🔒 Locked

pass data pointer via file to external program?

Started by SelethD Nov 3, 2004 at 2:36 PM 13 replies 1.4k views

Original Post

SelethD

177

SelethD

Nov 3, 2004 at 2:36 PM

Im not sure if this is possible to do, but here is what im trying. I have a control program lets call Master, Master allocates memeory, and loads game data, then writes the address of the globald data pointer GameData *data, to a file, ADDR.DAT Now I have two client type programs lets call Client Client creates an empty pointer of GameData *data, and reads the address stored in ADDR.DAT and assigns it into *data, so *data should point to the data in memeory under Master Now both the applications are running, so the data is still in memory at all times. When I read the ADDR.DAT address from a thread insinde the Master application, I can access the data. When I read the ADDR.DAT address from the Client application, I get garbage. So what is it im doing wrong? Or is there a better way to give an external application a pointer to data? Thanks

Washu

Mod

375

Washu

Nov 3, 2004 at 2:39 PM

Processes run in their own virtual memory space. You must make special calls in order to access blocks of memory across process boundries.

Fruny

203

Fruny

Nov 3, 2004 at 2:41 PM

Your two applications live in separate address spaces. Pointers from Master are utterly meaningless to Client and conversely.

You will probably want to use a shared memory block. Or a pipe.

doynax

Nov 3, 2004 at 2:43 PM

In systems with a memory manager all programs have their own unqiue address space. This is mostly for protection, without it any programs would be able to crash/modify any other program.
What you're describing is a technique called shared memory which uses a dedicated piece of memory to communicate within. However there's no guarantee that the two views of this block will share the same virtual address, so it probably can't contain any pointers.

You probably want to look into other communication methods as well. Here's a tutorial covering the most important ones (for unix but the same principles apply to win32).

aaron_ds

Nov 3, 2004 at 2:46 PM

Why have you opted for two executables over using two threads? It would seem that using two threads would more easily facilitate the transfer of data between them.

Just thinking about it, and you could also put the data into a seperate dll with a shared memory space.

Good luck.

SelethD

Author

177

SelethD

Nov 3, 2004 at 5:38 PM

Thanks for the info, the reason im not using different threads, but different applications, is because im trying to make a MUD for a BBS, and the client applications are run by users when they access the game from a node, so each player is running a client. Thats the only way to do it when your using drop files from the BBS.

Anyone know some good tutorials or info on how to set up a shared memeory area?

Or someone said use SQL for the games data, but I just cant understand it, are there any 'good' tutorials that teach this?

Im using VC++.net in WindowsXP, and if I go SQL im going to use SQLite.

Thanks

Max_Payne

Nov 3, 2004 at 5:43 PM

If you're programming a networked game you should be using TCP/IP for client-server communication... And yes, you can do that even if the client and server run on the same machine.

SelethD

Author

177

SelethD

Nov 3, 2004 at 5:47 PM

The BBS does all the networking stuff, I just have to worry about data sharing.

Max_Payne

Nov 3, 2004 at 6:02 PM

Quote:
Original post by SelethD
The BBS does all the networking stuff, I just have to worry about data sharing.

Which is a networking matter. You're overcomplicating your own life.

SelethD

Author

177

SelethD

Nov 3, 2004 at 6:07 PM

I guess I dont know how to explain it.

The BBS creates a drop file and runs the client program per node. The only access the game has to the bbs is through the drop file.

So if 5 people are on the bbs, and each one plays the game, then you have 5 copies of the game running. Each of these copies will be accessing your one set of data, and to keep them from writing while one reads, I need my own, way of controling access to the data, but I never have to actually hook a socket or anything like that, I just have to run the program as if it was a single user, but make sure no sharing violations.

Clear as mud, huh.

doynax

Nov 3, 2004 at 6:20 PM

Quote:
Original post by SelethD
I guess I dont know how to explain it.

The BBS creates a drop file and runs the client program per node. The only access the game has to the bbs is through the drop file.

So if 5 people are on the bbs, and each one plays the game, then you have 5 copies of the game running. Each of these copies will be accessing your one set of data, and to keep them from writing while one reads, I need my own, way of controling access to the data, but I never have to actually hook a socket or anything like that, I just have to run the program as if it was a single user, but make sure no sharing violations.

Clear as mud, huh.

The suggested solution is that you run a central server (coordinator) managing the game and let each instance of the program (local client) connect to the server through TCP sockets.
It's just using sockets to do local IPC. The benefit is that you can decide to move the actual server off BBS to another machine, and even allowing for a future client thats completely separated from the BBS. This is how most SQL servers works, even if the client happens to be located on the same machine.

You probably realise that there's at least a dozen other solutions to this problem. But by keeping the clients thin and only allowing a single application the manage the world's state you pretty much eleminate all synchronization issues.

SelethD

Author

177

SelethD

Nov 3, 2004 at 6:33 PM

Ok, I think I see now what you and Max are saying. It gives me a new look at things. I never thought of doing it that way. Having the clients connect to a server. I was just wanting the server to be like a traffic cop, and direct access to the data, which would be globally accessed by clients when it was their turn to use it.

Hmmm... Ill have to ponder things.

Thanks

Tonic151

Nov 4, 2004 at 2:12 PM

Quote:
Original post by SelethD
Ok, I think I see now what you and Max are saying. It gives me a new look at things. I never thought of doing it that way. Having the clients connect to a server. I was just wanting the server to be like a traffic cop, and direct access to the data, which would be globally accessed by clients when it was their turn to use it.

Hmmm... Ill have to ponder things.

Thanks

I do alot of bbs coding myself. Bascially if your going to use a multinode format, you will want to use Mutex's to lock and unlock the datafiles / functions that call them. So if node 1 is writting data to mud.dat, node 2 will wait till node 1 releases it's lock on the function, then node 2 will take over after node 1 has finished.