Hello,

I'm currently in the process of thinking out my plan for how enemies should interact with all clients within my networked world. My first thought has been to have a particular client act as the main client, where the enemies within the world will send it's particular Update (Transform, Attack, Death, ...) messages through this main client's Socket protocol. Upon the server end receiving these particular message it would then RELAY all clients, including the main client with the particular updates that the enemies are sending, upon the clients receiving the particular messages is when the Updates would be able to be visualized. It would seem the main client would possibly be quicker on re-acting since the server is currently hosted on the same machine, but it seems like it could be a good implementation assuming good latency for all clients.

The reason I've been thinking it might not be ideal for the client side to handle all enemy Updates without first sending them to the server, is because of the enemy possibly needing to target a specific player as well as needing to be in the same positions on each client's end or something like that.

Thank you for any insight.

If you're using the "client host" topology, where one client "hosts" and "runs the game server/level," then this falls out of that design.
The main draw-backs are that the client that is hosting may cheat, and if that hosting client drops out of the game, everyone loses that game. (Host migration is possible but really hard.)
However, you're also talking about your own "server" -- is that only used for matchmaking and forwarding messages?
The natural place to put server logic would otherwise be on your server, because you have control over it, and aren't subject to any individual client cheating or dropping out.

Thank you for the response. I have the main game application that is communicating with a dedicated server application. The server keeps track of the clients, multiplayer games and other associated information, such as which clients exist within the particular multiplayer game. As well as forwards the needed messages to the other connected clients about the event that just took place, other connected clients positional information, etc.

Currently, the server only knows what the client is sending it, which is where I'm becoming slightly confused on the best way for each connected client to know about the enemies within the multiplayer game world. I was reading somewhere last night that often times they do choose a particular client to act as the main client and it relays it's simulation, such as enemy positions, etc with the other connected clients.

Yes -- that's the "player-hosted game" variant. Very popular with many games, where a player will typically choose to "host/list" a game, or "find/join" a game. Although that decision can be made automatically for the player, without necessarily allowing player configuration of the hosted game.
It won't work at all for games that have any significant level of persistance, economy/trade of long-term value, and such, because the opportunity to cheat is so wide open. But it's great for FPS-es, RTS-es, and the like.