ClientCmd / ServerCmd "Rule of Thumb"
by Jeff Trier · in Torque Game Engine · 02/04/2004 (6:39 am) · 5 replies
Hi all,
For a long time I have wondered "When should I use ClientCmd and ServerCmd?"
From my understanding... A serverCmd is a command that the client has to run on the server, and a clientCmd is a command that the server tells the client to run on that client.
Assuming this is true, what kinds of functions do I want:
- The server to tell the client to run?
- The client to tell the server to run?
- The client/server to run without using clientCmd/serverCmd?
When looking through the files, there doesn't seem to be a pattern for where/when these differences are made.
I would think that the functions you don't want hacked should run on the server, but if that's the case, I want all the commands to run on the server... unless it's the HUD's appearance or something. But that would be a data transferring nightmare on any network, and since most functions are not tagged as server/client run, this thought is false under example.
For clientCmd, I would "think" it's only used for telling a specific client to run something, but couldn't the client do that on it's own without being told to do so by the server?
If anyone could help me wrap my head around this, I would appreciate it.
Thanks guys,
-Jeff
For a long time I have wondered "When should I use ClientCmd and ServerCmd?"
From my understanding... A serverCmd is a command that the client has to run on the server, and a clientCmd is a command that the server tells the client to run on that client.
Assuming this is true, what kinds of functions do I want:
- The server to tell the client to run?
- The client to tell the server to run?
- The client/server to run without using clientCmd/serverCmd?
When looking through the files, there doesn't seem to be a pattern for where/when these differences are made.
I would think that the functions you don't want hacked should run on the server, but if that's the case, I want all the commands to run on the server... unless it's the HUD's appearance or something. But that would be a data transferring nightmare on any network, and since most functions are not tagged as server/client run, this thought is false under example.
For clientCmd, I would "think" it's only used for telling a specific client to run something, but couldn't the client do that on it's own without being told to do so by the server?
If anyone could help me wrap my head around this, I would appreciate it.
Thanks guys,
-Jeff
About the author
Originally a Classical/Metal musician, I've always been attracted to anything involving computers, including: Networking, PC Building and Repair, software design and coding. I've been involved with game design and development for over 10 years.
#2
All network communication is done at the C++ level with the exception of message processing which can be used at the script level to handle Remote Procedure Calls (RPCS).
It's difficult to put these into context as you can use them for whatever purposes you desire but they range from simple messaging or state control to full handshaking of staged procedures such as mission loading.
The serverCmdXXXXX is the function that is executed 'on-the-server' as a result of a 'commandToServer' call from the 'client'. The clientCmdXXXXX is the function that is executed 'on-the-client' as a result of a 'commandToClient' call from the 'server'.
Perhaps some examples of its usage may help?
Say that the server decides that it's now time for all the clients to show a certain GUI screen because a certain event has happened. You would send a command to the client (from the server) and the clientCmdXXXX function (on the client) responds by showing the GUI in question.
Say that the client wants to 'REQUEST' that the server do something but you don't want it to allow a client to 'DEMAND' it as someone could hack-in the command at a later date. What you would do is use a 'commandToServer' that runs a serverCmdXXXX function (on the server) and the server decided if the client could in-fact actually do it based upon some kind of authentication criteria.
Say that you want to send some bulk information to the client but you wanted to do it in stages. What you can do is set up a cascade of commandToClient/commandToServer calls to handshake their way through it. You'd start by initiating the cascade by the server sending a commandToClient (to the client) which did some work. The client would then acknowledge with a commandToServer (to the server) and the server would then continue by perhaps downloading some information (possibly also using commandToClient). The server could then move onto the next stage and use another commandToClient to start the next stage and the client would get ready and then acknowledge with a commandToServer etc etc. This is what happens when the server sends the new mission details/ghosts/datablocks to the client during your start-up phase.
Near realtime communications e.g. positions of objects and their control should really be done within the C++ framework but this really depends upon the game itself.
Does this help somehow? Are there any other points I missed?
- Melv.
02/04/2004 (9:09 am)
Jeff,All network communication is done at the C++ level with the exception of message processing which can be used at the script level to handle Remote Procedure Calls (RPCS).
It's difficult to put these into context as you can use them for whatever purposes you desire but they range from simple messaging or state control to full handshaking of staged procedures such as mission loading.
The serverCmdXXXXX is the function that is executed 'on-the-server' as a result of a 'commandToServer' call from the 'client'. The clientCmdXXXXX is the function that is executed 'on-the-client' as a result of a 'commandToClient' call from the 'server'.
Perhaps some examples of its usage may help?
Say that the server decides that it's now time for all the clients to show a certain GUI screen because a certain event has happened. You would send a command to the client (from the server) and the clientCmdXXXX function (on the client) responds by showing the GUI in question.
Say that the client wants to 'REQUEST' that the server do something but you don't want it to allow a client to 'DEMAND' it as someone could hack-in the command at a later date. What you would do is use a 'commandToServer' that runs a serverCmdXXXX function (on the server) and the server decided if the client could in-fact actually do it based upon some kind of authentication criteria.
Say that you want to send some bulk information to the client but you wanted to do it in stages. What you can do is set up a cascade of commandToClient/commandToServer calls to handshake their way through it. You'd start by initiating the cascade by the server sending a commandToClient (to the client) which did some work. The client would then acknowledge with a commandToServer (to the server) and the server would then continue by perhaps downloading some information (possibly also using commandToClient). The server could then move onto the next stage and use another commandToClient to start the next stage and the client would get ready and then acknowledge with a commandToServer etc etc. This is what happens when the server sends the new mission details/ghosts/datablocks to the client during your start-up phase.
Near realtime communications e.g. positions of objects and their control should really be done within the C++ framework but this really depends upon the game itself.
Does this help somehow? Are there any other points I missed?
- Melv.
#3
Melv,
Thanks for the lengthy description. I have a MUCH better understanding of how this all works. Especially hearing how the communication is mainly done through C++.
So if I get this right, spawning a new aiPlayer or object can be initiated by any client (not using a clientCmd/serverCmd function), and the other clients & the server will be aware of it because that particular information is being sent from script to C++, then through the network?
If this is true, then I think I get it. :)
Thanks,
-Jeff
02/04/2004 (6:32 pm)
Thanks for the response guys!Melv,
Thanks for the lengthy description. I have a MUCH better understanding of how this all works. Especially hearing how the communication is mainly done through C++.
So if I get this right, spawning a new aiPlayer or object can be initiated by any client (not using a clientCmd/serverCmd function), and the other clients & the server will be aware of it because that particular information is being sent from script to C++, then through the network?
If this is true, then I think I get it. :)
Thanks,
-Jeff
#4
The typical 'model' used to generate, distribute and provide server/client communication via script through to C++ goes something like this but it is not written in stone:-
On the server (which is a notional aspect when the server/client is running within the same process), you generate the object in question with the scripts which in turn create the C++ object and register it with the system. If, and only if, the object is network capable and set to ghost e.g. a NetObject with the appropriate NetMask, then the engine will ensure that each and every client both current and new will get a ghost copy generated on their system. The object itself then takes over and triggers, at its convenience, data required on the client objects for them to do their job.
All changes to the master object (on the server) result in the server object (and this is again down to how the object is written) triggering a network update to the clients using the packUpdate/unpackUpdate calls within the NetObject infrastructure.
I think I go into the details a little further here.
- Melv.
02/05/2004 (10:07 am)
Jeff,The typical 'model' used to generate, distribute and provide server/client communication via script through to C++ goes something like this but it is not written in stone:-
On the server (which is a notional aspect when the server/client is running within the same process), you generate the object in question with the scripts which in turn create the C++ object and register it with the system. If, and only if, the object is network capable and set to ghost e.g. a NetObject with the appropriate NetMask, then the engine will ensure that each and every client both current and new will get a ghost copy generated on their system. The object itself then takes over and triggers, at its convenience, data required on the client objects for them to do their job.
All changes to the master object (on the server) result in the server object (and this is again down to how the object is written) triggering a network update to the clients using the packUpdate/unpackUpdate calls within the NetObject infrastructure.
I think I go into the details a little further here.
- Melv.
Associate Ron Yacketta
-Ron