Enginuity: Client/Server
Author
I've been working off the Enginuity tutorials and have gotten to designing a client and a server.
This is my basic setup: a plugin based system.
The dlls are completely isolated from other dlls (as they should be!) but this also makes it very hard to find an elegant solution to the problem.
I would like to stay away from linking the clients back to the application manager. I originally had them linked back, but the result was a web of dependencies and ultimate frustration that was unnecessary.
I'm contemplating initializing the linkup via the loop back. The server would load first and the client second. The client would then attempt to establish a link via TCP/IP to the server. They would then send points to themselves to each other and allow for a direct memory link between the two.
How do you allow for encapsulated dlls to communicate between each other?
How is your client/server communication established?
Thanks in advance!
Author
I've already implemented a plugin system. Going back to a single executable to solve this problem would be a step backwards. It would ruin all hope of the extensibility I have created.
I like this architecture. Very, ... newave :)
Well, I'm not entirely sure what you are asking, or I fail to see the problem, or I'm just plain dumb.
DLLs are just library you plug into one application, so they should really be able to share memory like any other DLL-based app. And that would be solely for shared resources, like collision maps, objects, and whatnot, for the sake of saving some memory.
All other communications should be done by the network layer, and done by simple message passing, like for a server with a remote client. The network layer maybe should be able to shortcut the transport layer (winsock) entirely if the server send a message to the client side of the same application, but that's about it.
You may want to add network tasks to your diagram too, since it's quite a key component.
does that answer anything? :)
Well, I'm not entirely sure what you are asking, or I fail to see the problem, or I'm just plain dumb.
DLLs are just library you plug into one application, so they should really be able to share memory like any other DLL-based app. And that would be solely for shared resources, like collision maps, objects, and whatnot, for the sake of saving some memory.
All other communications should be done by the network layer, and done by simple message passing, like for a server with a remote client. The network layer maybe should be able to shortcut the transport layer (winsock) entirely if the server send a message to the client side of the same application, but that's about it.
You may want to add network tasks to your diagram too, since it's quite a key component.
does that answer anything? :)
sorry, OK, it's slowly starting to make sense. You want two applications, one client, one server. I think that's overkill really. Anyhow, I don't think you would be able to share the resources the same way, if at all. Else, it should be just standard networking protocols, no different from a server / remote client. To launch the application could be tricky, but the server could spawn the client and wait in a NULL state to startup, and the client would remote-console the server to set it up and launch the game with the required map, game mode, number of players, ... Or something like that...
I'm just rambling, ...
I'm just rambling, ...
Author
I think I've decided to use a thrid dll to connect them. The third would have a shared memory space thus able to link data between the client/server. Although this may be overkill for a single player game, it will be VERY easy to port the server into a multi player environment. Infact, I could probably use the same serverdll to host single AND multiplayer games.
Thanks dooz for the private message!
Thanks dooz for the private message!
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement