Sign in to follow this  

Creating dedicated server, question about splitting Client's and Server's code

This topic is 2044 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

Hello, i am creating:
1) Client application which suppose to connect to remote secure dedicated server
2) Secure dedicated server

I am hiding server logic, so i need to hide server code too.
So what do i do for that ?

For example i have single object type: Player,
i split this class into two classes: ServerPlayer, ClientPlayer and writing them totally from scratch,
but it is totally the same objects, semanticly, so i think i am doing something wrong,
because this objects have much "Common" fields, but again most of that fields also splitted into: Client and Server types,
so i think i cant just combine this classes with inheritense.
How do you writing server and client code, when you need to hide much server logic ?

I am thinking about combining ServerPlayer and ClientPlayer into one Player class, and other similar classes also,
but dont know how to do it better (C# or C++), and should i do this at all ? may i should use splitted classes ?
I think i could combine these classes into one Player with #if/#endif:

[CODE]
// now i have for example:
class ServerPlayer
{
int ID;
void HandleMessageFromClient(){}
}
class ClientPlayer
{
int ID;
PlayerModel Model;

void SendMessageToServer(){}
}
// and want combine into:
class Player
{
int ID;
#if CLIENT
PlayerModel Model; // some fields Server do not need also
#endif

// need to hide server functions from client
#if SERVER
void HandleMessageFromClient(){}
#endif

// dont need to hide client functions from server
void SendMessageToServer(){}
}
[/CODE]

so what should i do ? continue using splitted classes and split everything into Server/Client prefix, or use single Objects, because they are semanticly the same ? Edited by newbprofi

Share this post


Link to post
Share on other sites
What do i think about it:
1) Well, first of all, its not necessarily to hide "Variables" on client, i think "Null" value for them is enaugh, and also "Null/Dummy" types for that variables.
2) Hiding functions is only necessary or critical.
3) Using NON-splitted single classes is handy, because we dont have to write also separate containers/managers for Client and Server objects.
4) NON-splitted classes still need to split much functions into Client and Server.
5) NON-splitted classes are very dirty and ambiguous, because of #if/#endif everywhere. Though in C++ its not a big problem, we can use macros, but for C# its kind a problem.

The main option here (3) for benefit of single NON-splitted classes.

But again and again i come back to "Splitted classes", because its:
1) Cleaner. You dont have to write #if/#endif every where.
2) It shows you clean Server and clean Client logic, without any mixing.
3) Easier to create and maintain.

Also have minuses:
1) The same objects need to be implemented twice.

Ofcource, many game engines use "NON-splitted objects", they just have flag "IsServer" or something like that. But they all support only "Client-side-Server", they dont have to "Hide" any server code or logic, every player may create/host own game. But i am creating Master Server, players cant create own server or host games, they have to connect to remote server for playing. Like in MMOG.

I know the main rule for writing networking applications is: "Separate Server and Client code", thats what i am doing actually. Edited by newbprofi

Share this post


Link to post
Share on other sites
"Hiding" code is a form of "security through obscurity," which doesn't work if there is an even semi-persistent attacker.

Your server will see messages come in from the internet. These messages may be generated by your client. Or they may be generated by a client that someone has modified. Or they may be generated by some program that has nothing to do with your client code at all. Your server *cannot* tell these kinds of messages apart, assuming the attacker is even moderately skilled. Thus, if you care about cheating, you have to design the protocol so that the client sends "requests" (user interface input) and the server actually modifies the game state and sends "results." Note that it's totally OK for the client to "guess" what's going to happen on the server, and show that to the client, to avoid the round-trip time for each command, as long as there's a way for the client to re-sync if the expected outcome didn't actually happen. You can also use this to optimize transmission of commands and results.

I would highly recommend trying very hard to build a game that works great, without worrying about cheating. 99.9% of all games don't have a cheating problem, simply because they're not good enough games that anyone would care to cheat anyway. First, you need to figure out how to get into the 0.1%, then you can worry about cheating. As long as you have a proper client/server network protocol, the impact of cheating will be small (think "aimbots" rather than "treasure duplication.") Edited by hplus0603

Share this post


Link to post
Share on other sites
I disgree with hplus0603.

All online games where people can cheat, they cheat, even the bad ones. For some people, finding a way to cheat is their game and cheating is quite simple nowadays. If you launch a very good game, when cheaters emerge and you are too slow to react, what do you think will happen?

Always start the foundation at the very beginning of a project saves you time and headache afterwards, reimplementing stuff afterwards is so much headache.

I hide code from the client whenever it is possible. You have to create two complete different objects, whereas client does the visual stuff, client-side game mechanics and server does the damage dealing, cheat/speed checking and server game logics (e.g. dealing damage etc.).

In some cases when the offset is too big between client and server, the server adjusts this on the client or clients. What I do is, when client does an action it sends a RPC call to the server object, server object verifies and confirm the results on the client(s).

Might sound like a lot of extra work, but it is actually not. In a FPS for example, on the client it only need to know when he is allowed to shoot and what direction the bullet he is aiming and what speed to show the visuals. The server is the only one allowed to deal damage with that information sent from the client. Edited by laapsaap

Share this post


Link to post
Share on other sites
[quote name='hplus0603' timestamp='1336407889' post='4938091'][/quote]
hiding server code is not only anti-cheating measures.
hiding server code is needed to hide server logic:
1) To hide Server "BUGS" from potential hackers and cheaters. - this is very FIRST point of splitting Server/Client code.
2) To hide Server "Random" events mechanisms.
3) To hide Server "Anti-spam"/"Anti-Bot"/"Anti-Cheat"... protections.
... man, this list doesnt have end. Your "Client" events/packets is just have nothing similar to this question.
Lol ofcourse i know that server need to check every packet from client. There is a lot measures according to this, including packet encoding.

[quote name='laapsaap' timestamp='1336420272' post='4938168']
I hide code from the client whenever it is possible. You have to create two complete different objects, whereas client does the visual stuff, client-side game mechanics and server does the damage dealing, cheat/speed checking and server game logics (e.g. dealing damage etc.).
[/quote]
exactly. I dont know even 1 MMO game which have public server code inside client.

Anyways, question is not about "Splitting vs Not splitting at all",
question about "How to" split server/client code:
1) Create different Classes for Server and Client
OR
2) Create same classes, but with splitted Fields and Methods.

Well ok, i decided to continue use (1) option. Edited by newbprofi

Share this post


Link to post
Share on other sites

This topic is 2044 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