communicate between different appdomain in different processes

i need to create communication between 3 exe through a dll were all of them could access/change it's variables (lets say authserver, gamesever and cp)
so as of being static isn't enough as static is per appdomain it's getting kinda tricky for me as
i don't really want to support remoting or wcf
that's why i was hopping for a way around that and preferable not to be writting to database or even flat/xml file

Can't you just use something named pipes, shared memory, or sockets maybe?

Quote:

Originally Posted by Best Coder 2014 Can't you just use something named pipes, shared memory, or sockets maybe?

pipes and sockets would be messy with maybe 200 variable (yeah imagine switching on 200 variable with text i piped between clients and server to get a value then cast it back to new objects) but yeah it would work but i just dun like it

and duno what you mean by shared memory, if i've to guess i would say like memory mapped file ? well i guess instead of that in that case a text file would do with 2 threads checking, one write from gui to it and one read on gameserver

but i was hopping for a better way around, because at every cases i would have to duplicate all my variables

If you're doing this just to create an account server, game server, and control panel, then use sockets or pipes (if you don't care about running them independently on different hosts). There's absolutely no reason to do weird tricks to communicate between the three. If you're really concerns about switching between 200 different packet types (though you really shouldn't have that many), use a tree data structure where the id is the key and the function pointer is the value.

Quote:

Originally Posted by OverKillasdwqe pipes and sockets would be messy with maybe 200 variable (yeah imagine switching on 200 variable with text i piped between clients and server to get a value then cast it back to new objects) but yeah it would work but i just dun like it and duno what you mean by shared memory, if i've to guess i would say like memory mapped file ? well i guess instead of that in that case a text file would do with 2 threads checking, one write from gui to it and one read on gameserver but i was hopping for a better way around, because at every cases i would have to duplicate all my variables

It sounds to me like this might not be a very good idea. Why would you want something like that? I mean something where one process can change the variables inside another process? Sounds really messy, are you sure there's not a better way?

well a better way i think would be including both at the same project where it's console generating the gui or the gui generating the console, then it would be 2 threads but in the same appdomain and there would be no problem but in that case i would either stick the gui to gameserver or to the auth server

or even a better design would be turn game and auth servers to be a gui based

so why do i need this ? i need to be able to set variables at game server from a separate control panel, why ? im doing my best to have a perfect up time with everything dynamic that i could literally change anything (like within tq binaries) but from a control panel

but the thing is, im not searching for a solution as much as im seeking information to learn :)

I would suggest opening another port for a webserver and doing it via something like PHP then.

Quote:

Originally Posted by KraHen I would suggest opening another port for a webserver and doing it via something like PHP then.

Websockets would be his best call then.

I would strongly advise against a GUI for your server applications. I've learnt my lesson with that. Always support command line automation before GUI driven controls. Also, it really isn't best to have a GUI for a performance sensitive application. Hopefully if you decide to implement a GUI that you thread it correctly. The default threading apartment model for Windows Applications (non-console) can negatively affect your server.

Quote:

Originally Posted by turk55 Websockets would be his best call then.

I don`t see the need of the added websocket protocol, but yeah, it would be a straightfoward solution in the end. Also, very easy to implement.