how to make a server? i have a pc, ok... connect it to internet and thats it?
A server is just a computer that accepts incoming connections.
A service is a program that accepts incoming connections.
Typical internet services customers get are very asymmetric. Maximum download bandwidth (from internet to customer) is often almost an order of magnitude more than upload bandwidth (customer to internet). Providers often have all sorts of firewalls in place to stop or reduce port scanning of clients' computers, and may even stop connections to specific ports (standard services use a fixed TCP and/or UDP port number, between 1 and 65535).
Internet service providers usually have a different contract for customer servers. These are usually more expensive.
A better option is to rent the hardware and the internet connection as a package, with the physical hardware somewhere in a server hall you often cannot get physical access to. This is called
hosting. (Well, if you rent a specific physical server, then physical access is often possible to arrange, but isn't usually easy.) Currently, the best bang for buck is to rent a virtual server. Essentially, the service provider provides an internet connection suitable for a server, and a virtual machine (virtualized using processor features, not just hand-wavy "virtual" virtual) with limited CPU power and storage capacity, but usually with the basic OS maintained by the provider, and data backed up regularly. You can usually easily switch to beefier virtual server with little extra cost as your needs change.
how do i get a unique IP address? through internet registars? ISP? or what?
Through your internet service provider. They usually buy entire ranges (that can be quite small), and then rent a fixed IP for you.
Note that domain name system, DNS, is a separate service. It manages the mapping between names and IP addresses (like
www.nominal-animal.net to
188.165.143.18). You can rent a specific name from a domain name registrar, but to associate it with an IP address, you'll also need to rent domain name services. Usually, you buy this service through your hosting provider, as good hosting providers have good packages for this.
2) how to avoid ddos attack on a simple server?
Distributed Denial of Service attacks are essentially just a lot of clients connecting to your service. They either use up the entire network bandwidth for that server, or all of available processing resources, so that the service essentially jams. (Technically, that requests cannot be serviced in a reasonable time.) If the connections are secured using SSL/TLS, a major issue is that the initial handshake is very CPU intensive.
You cannot really protect anything against a DDOS; you can only mitigate such events.
How to mitigate DDOS situations -- or even normal situations where your service becomes suddenly inundated with clients, because it was discussed in a Slashdot article (
Slashdot effect), or maybe went viral on Fakebook, Twatter, or Utube, or similar --, depends on the service itself.
Game services can mitigate DDOS by separating the initial connection (login or registration) to separate machines from the machines doing the realtime services. The initial service passes the client information and symmetric key(s) used to protect the communications to the realtime service; and the realtime service simply dumps a client if a symmetrically encrypted message does not validate.
Symmetric ciphers are used because they are fast. They are called symmetric, because both ends must know the same key; one end uses it to encrypt, the other to decrypt. Sometimes two different keys are used, one each for the direction of the data flow; especially when the key itself is changed (to avoid certain other types of attacks). Initial connection cannot use symmetric ciphers, and are typically based on public-key cryptography and key exchange protocols, that are orders of magnitude slower.
Some hosting providers do provide DDOS mitigation services. There are many ways of providing that, but in the simplest case, it is a selective firewall that blocks new connections when the protected server says it cannot handle more concurrent clients, and only allows already established connections through. (Note that each TCP/IP and UDP/IP connection is identified by two pairs: sender IP and port, and recipient IP and port.)
A smart game server can provide some level of robustness against DDOS attacks, by maintaining a firewall that only accepts incoming data from specific IP address and port pairs. (In Linux, this means that the kernel does receive each such packet, but discards all but speficially allowed ones. While this does consume CPU resources, it does allow saturating a typical 100 Mbit/s network connection without the machine keeling over due to insufficient CPU resources.)
Unfortunately, there is no universal hammer that solves all DDOS issues. Software engineers who have maintained game servers under DDOS attacks could describe much better strategies, but a lot of it is Secret Sauce...
i heard big corp like amazon have "elastic infrastructure" to deal with this.
Well, yes. They just throw enough network bandwidth and CPU resources at the beleagured service, so that it can service all the incoming requests -- or at least service the real ones, and sufficiently process the attack requests to drop them on the floor.
if i and you log in to the same game, and i shoot you. i see you dead in my PC
Well, that's not exactly how it works.
The game server is not just an information relay; it nowadays also has to be a kind of a referee. So, when you shoot at another gamer in your own machine, it sends that information to the server for the server to make the decision. The server makes the decision, and forwards the result to all players in the same room/zone (well, anyone that is affected by the information).
Then, on your computer, you see the other player either getting shot or not.
The reason is that a lot of gamers are assholes, who will try everything they can to win, and often modify their copy of the game (through run-time modifications, or mods). In the earliest multiplayer games, each game instance would make the decisions locally, but nowadays, that is not safe anymore. (Some games do still do it that way, but keep enough logs on the game server, to check the data afterwards to see if a player cheats more than once. It varies; Secret Sauce again.)
This is also why
ping times, or data packet roundtrip time, is so important to gamers. If you have long ping times, more stuff has time to happen on the game server before your actions are noted.
One reason computational physicists are sometimes valued in game development teams, is that they have experience with
predictor-corrector methods. Essentially, during the time local game events are sent to the game server, the local instance runs in "predictor mode", where actions are
tentative. You have minimal lag, but sometimes the predictor is so far off from what actually happens, that the correction due to response from game server causes a human-noticeable glitch. Typical examples are a player falling off the same cliff twice, or falling off and then magically not, continuing traipsing along that cliff.
(I could go on and on about such algorithms, and some of their properties; like gear5 predictor-corrector and how it is used in molecular dynamics simulations to allow longer time steps, and how that corresponds to minimizing the effects of lag in games.. but I'm waffling already.)
how all this data is managed by a game server? how the 3D map is shared? is it stored in the game server? or stored in the users PC?
Carefully, and both the server and the clients have a copy of the same data.
At the very start of the game, each player should have an exact copy of the game server state. This includes not just the map, but all properties of all interactive objects and players and non-player characters. This is essential, because as the game progresses, it allows the server to update the state on all clients by simply sending the
delta, the difference or change in the state.
Note that often only the most important information is transferred. For example, if a player throws a crate, there is no need to transfer the coordinates in real time; rather, the trajectory is modelled as a curve (as a function of time), and the coefficients of that curve are transferred instead. If a player destroys a crate, there is no need to describe how the pieces fly around, as it is just visual candy; instead, the game server just tells the other players when and how the crate was destroyed, and they show a roughly appropriate animation.
(In many games, passing through doorways between zones has funny glitches because of this. In one zone, the doorway may be closed, and in the other, open. So, when the player sees the door open, they see the other players in the other zone running futilely against an invisible door; and in the other zone, they see a player emerge through a closed door. To avoid this, the server would need to maintain a single set of information about doors crossing zones, but that can violate the single-zone assumption about communications about events, so there may not be any "clean" way to fix such issues without causing significant overhead on the game server.)
Player movement is one of the things that requires heavy predictor-corrector algorithm use to keep everything "smooth", instead of things happening in visible steps (of packet roundtrip time). Another approach is to let each player be a fixed timestep duration ahead of other players on their local machines, but adjust the others movements and firing to compensate. This allows for absolutely smooth operation, but player actions do not exactly match across all player machines -- but their results still do.
well looks like not so many question isnt it?
I don't know if this helped any, but I got to talk about stuff I like to talk, so it was a win for me
Home
Help
Search
Login
Register
