Sign in to follow this  

Enginuity: Client/Server

This topic is 4859 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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!

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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? :)

Share this post


Link to post
Share on other sites
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, ...

Share this post


Link to post
Share on other sites
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!

Share this post


Link to post
Share on other sites

This topic is 4859 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this