Depends on what type of multiplayer game it is your talking about. A FPS would *probably* include both server code and client code(For hosting and joining, respectively).

And yes, as far as i know you need to code the server differently because it's also sending/recieving alot more information.

Hope this helps a little!

well, server wil be mostly entity sending states, by the hundreds possibly, while the client will be receiving them. Most of the client sending data is to do with client inputs, so the data is very small (theoretically, while you need to compensate for packet loss and lag compensation).

So that's the difference between client and servers. Server sends, client receives.

If the server dies, you're screwed. Server has to be on all the time, else clients will stall, since they won't be receiving any states from the server, who does all the work (AI, movement, ect...). The client only receives states, like position, orientation, health, impact data, to produce all the rendering, special effects, sounds.

Server is receiving a lot of info, since you will have a lot of users, but each user will send a small amount. Hence the requirement for servers to be capable of receiving, but especially sending data to loads of clients.

The way a client connects to a server is usually via a direct connection (connect to ip:port). The server accepts or reject it, then the communication between server and clients can start, amd the server sends stuff towards the client. That's how the client sees the server. You can also have a server browser, where each server reports to a special server that lists all the active servers on the web. Then you pick one up on the client and connect to it.

It's nothing special compared to P2P.

The server code should be completely separated from the client code. You should have a set of client entities on the client side, receiving data from the server entities on the server side.

Both types of entities are completely different in terms of code and logic. It's as if an entity, like in a single player game, is split into two objects, a server (doing the physics, AI, state change, damage calculations) and a client (doing the rendering, animation, sounds, from states sent by the server entity).

All client entities on all the client machines concerned receive states (via a message broadcast for example) from one single server entity held on the server. That's how all clients are synchronised and singing the same tune.

For example, a dedicated server should not have any client code whatsoever, since it does not need to render anything. It's all pure server entities. Dedicated servers are therefore console applications, with a console output, and a console input for managing the server. If you take the pure route of separating entities into two server/client objects, you can benefit from encapsulating server code and client code into 2 distinct DLLs, and shared code (math tools, helpers) into another one.