technology NAT & Connection Improvements

[Khaoios 1,970]

Well, in addition to Network Security, I thought I drop this down that a friend of mine and I wrote.  It will explain details on NAT and Improving Connectivity in your home (you can do this with almost anything that requires connection, like your Computer, Laptop, Mobile Device, Xbox, PS4, whatever.  Feel free to take a moment and read through it and hope it serves as a guide,

 

What is a NAT?

NAT stands for Network Address Translation. Basically, your ISP gives you ONE IP address through your Modem. Your Router takes all devices (Computer, Printer, Xbox, PS4, etc) attached to the router, and assigns them "private IP addresses". The NAT then translates these private addresses into the single IP address given to you by your ISP, thus allowing you to connect multiple devices.

How Can I Improve My Connection?

1) Go WIRED
Wired is simply faster than wireless. It's also more reliable and consistent. Though not as convenient, just a better way to go.

2) Call your ISP (Internet Service Provider, ex: Optimum, Verizon, AT&T, Comcast, etc.)
Try visiting http://www.speedtest.net/ and running a test. If your results are lower than 10MB/s download, 1.5MB/s upload, and more than 40 ping, you should try to improve your connection (Note, these numbers change depending on variables such as if you are wireless, how far you are from your router, and what type of Ethernet cord you are using). If you are getting results lower than you are paying for, ask them to fix it.

3) Port Forward
This is where you're going to make a huge difference at no cost but your own time. Let's take Xbox LIVE as an example (This will apply to PC's, etc).  Now, this prefers certain ports on your router for connections. However, sometimes these ports are used by other things on your network. Port Forwarding these ports to your Xbox's connection "reserves" these ports specifically for Xbox LIVE. This process will also Open your NAT.

To continue with this process, go to a PC you have at home. Open up an internet browser (Internet Explorer, Firefox, Chrome, etc.) and type in your home IP address (this is usually 192.168.1.1 or 10.0.0.1). You will now be asked for a login and password (the login is usually admin and the password is usually password unless you changed it). Now, locate a section called "Port Forwarding" or "Port Triggering" or "IP Forwarding" or something similar (every router is different).

Once you have found the Port Forwarding settings, look for an option called "Add" or "Add custom Service" or something similar. Once you find it, click it. You are now going to enter 10 separate items to this list. When you add an item, it is going to ask you for 4 things. It will ask you for a "Service Name" (or something similar), a "Start Port", an "End Port", and a "Server IP Address" (or something similar). For the Service Names, simply put something you'll remember, such as "Xbox_LIVE1", "Xbox_LIVE2", "Xbox_LIVE3" etc for all 10 times. You will put in the Start and End Ports I list below. For the IP Address, put something similar to what your router's IP address is, but with a different number at the end. For instance, if your router's IP is 192.168.1.1, then make your Xbox's new IP 192.168.1.55 or something like that. That last number can be anything between 1 and 255. However, choosing a higher number such as "55" will prevent any problems with other connections in your household trying to use the same number (connections count up, so you'd have to have 55 connections in your house to have a conflict). Next, you will add these connections I list below in the following format (NOTE: your Service IP Address may be different than mine):

Service Name - Start Port - End Port - Service IP Address - Connection Type
Xbox_LIVE1 - 3074 - 3074 - 10.0.0.55 - TCP/UDP
Xbox_LIVE2 - 80 - 80 - 10.0.0.55 - TCP
Xbox_LIVE3 - 88 - 88 - 10.0.0.55 - UDP
Xbox_LIVE4 - 53 - 53 - 10.0.0.55 - TCP/UDP
Xbox_LIVE5 - 77 - 77 - 10.0.0.55 - TCP/UDP
Xbox_LIVE6 - 3330 - 3330 - 10.0.0.55 - TCP/UDP
Xbox_LIVE7 - 1900 - 1900 - 10.0.0.55 - UDP
Xbox_LIVE8 - 2869 - 2869 - 10.0.0.55 - TCP/UDP
Xbox_LIVE9 - 10243 - 10243 - 10.0.0.55 - TCP/UDP
Xbox_LIVE10 - 10280 - 10284 - 10.0.0.55 - TCP/UDP(WATCH OUT, this one's end is different than the start!)
Xbox_LIVE11 - 1863 - 1863 - 10.0.0.55 - TCP/UDP

Now, you may notice that unlike other IP forwarding guides, I forward 11 services rather than the 5 or so they do. That is because those extra services are for Video connections and such that Xbox LIVE uses as well. Think of it as a FULL 360 port forward, not just gaming.

Now, you are going to need to open up Command Prompt. You can do this by going to "Start" and clicking "Run" or by holding the "Windows" button your keyboard, and pressing the "R" key. Once it pops up, type in "cmd" (without the quotes) and press Enter. Now you have opened Command Prompt. Now type in "ipconfig /all" (without the quotes) and press Enter. A bunch of info will be listed. Look for a section labled as "Ethernet adapter Local Area Connection". Look for the info labeled as "Subnet Mask", "Default Gateway", and "DNS Servers" and write down the addresses they list.

Now, it's time to change your Xbox's IP settings. Go to your Xbox and turn it on. Now go to the System Settings by going to the "My Xbox" section and scrolling right. Open it up and look for "Network Settings". Select your connection type, and then change your settings from Automatic to Manual. It will now ask you what your Xbox's manual IP address is. Now input the IP address you chose (I have been using 192.168.1.55 for an example). You will also be asked for your Subnet Mask and DNS Servers, which you can fill in with the information you wrote down earlier.

 

4) Improve your Hardware
This includes upgrading your Router, Modem, and Ethernet cords. As far as your Modem goes, you're probably renting from your ISP. Try going into their office and asking for an updated model. Otherwise, try to buy your own. A good quality gaming modem is the Motorola Surfboard Extreme. You may also want to look for an updated router. Try looking for any form of Gigabit router for a reasonable price. If you wish to stay up with current times, make sure it is a Wireless N router as well. An example would be the Netgear WNDR3700.

After that, change your ethernet cords to CAT6 Ethernet Cables. Though Xbox 360 cannot fully utilize them, they are significantly more reliable than CAT6, if for nothing more than lower packet loss. Be aware that having a CAT6 cable between your Xbox and Router means nothing if you're still using a CAT5 or CAT5e between your Router & Modem.

Additionally, here is a little more information to know and check to make sure you are fully optimized:

1. Xbox live certified routers/modems list.

2. Switch off wireless in your router if you're not using it, it takes resources and latency away from your router response times.

3. Switch off devices communicating with your router/modem and therefore competing with your xbox e.g. you siblings using a laptop or your mobile phone checking email.

4. Signal to Noise Ratio, contact your ISP or check your toolbox/account settings with your ISP. Usually they have settings they or you can set specifically for gaming configurations. Gaming prefers a more persistent connection over say large downloads for example. ISP/broadband can be configured in many ways to handle this and this can change per ISP too.

5. Router level: disable ping to stop a common form of cheating.

6. Router level: enable/disable packet security, stop cheating but adds some latency.

7. Router level: Maximum Transmission Unit (MTU) setting requires a minimum of 1364, you can change this in your router to a maximum of 1500. This is the largest "chunk" of data at any one time your router can communicate, try increasing this to recommended 1452 to gain more performance.

8. Cable level: Shorten your cable distance between router/xbox. Also keep cables untwisted and away from power cables.

9. Quality of Service Rules (QoS): You can set rules in your router for which data traffic has the highest priority. Helpful in shared dorms/houses for example.

10. Demilitarized Zone or DMZ: is more open method for allowing open NAT as well as a faster method than port forwarding as the router essentially has no filtering work to do. It means your xbox is outside of any firewall/router protection but is free to communicate with xbox live, game hosts or game clients. Having port forwarding enables protection against things like packet flooding, ping flooding and other basic network manipulation cheats. However using a DMZ is a simplistic and fast method for maximising your gaming experience.

After you've entered all the new information, restart your Xbox, and enjoy your improved connection.  As mentioned before, this is an example of improving connection, and can be applied to PC connectivity. 

 

 

[Khaoios 1,970]

Gonna update the full info, however, I want to mention and everyone knows about this.  Lags............our worst nightmares, however, common in gaming, yet, on the PC, it gets a little different. 

[Khaoios 1,970]

What are Lags?

 

Commonly found in online gaming, a lag is a noticeable delay between the action of players and the reaction of the server. Although lag may be caused by high latency, it may also occur due to insufficient processing power in the client and/or server.  The tolerance for lag depends heavily on the type of game. For instance, a strategy game or a turn-based game with a low pace may have a high threshold or even be mostly unaffected by high delays, whereas a twitch gameplay game such as a first-person shooter with a considerably higher pace may require significantly lower delay to be able to provide satisfying gameplay. But, the specific characteristics of the game matter. For example, fast chess is a turn-based game that is fast action and may not tolerate high lag. And, some twitch games can be designed such that only events that impact the outcome of the game introduce lag, allowing for fast local response most of the time.

 

What are its Causes?

 

While a single-player game maintains the main game state on the local machine, an online game requires it to be maintained on a central server in order to avoid inconsistencies between individual clients. As such, the client has no direct control over the central game state and may only send change requests to the server, and can only update the local game state by receiving updates from the server. This need to communicate causes a delay between the clients and the server, and is the fundamental cause behind lag. While there may be numerous underlying reasons for why a player experiences lag, they can be summarized as insufficient hardware in either the client or the server, or a poor connection between the client and server.  Hardware related issues causes lag due to the fundamental structure of the game architecture. Generally, games consists of a looped sequence of states, or "frames". During each frame, the game accepts user input, performs necessary calculations. When all processing is finished, the game will update the game state and produce an output, for example in the form of a new image on the screen and/or a packet to be sent to the server. The frequency at which frames are generated is often referred to as the frame rate. As the central game state is located on the server, the updated information must be sent from the client to the server in order to take effect. In addition, the client must receive the necessary information from the server in order to fully update the state. Generating packets to send to the server and processing the received packets can only be done as often as the client is able to update its local state. Although packets could theoretically be generated and sent faster than this, it would only result in sending redundant data if the game state cannot be updated between each packet. A low frame rate would therefore make the game less responsive to updates and may force it to skip outdated data.  Conversely, the same hold true for the server. The frame rate (or tick rate) of the server determines how often it can process data from clients and send updates. This type of problem is difficult to predict and compensate for. Apart from enforcing minimum hardware requirements and attempting to optimize the game for better performance, there are no feasible ways to deal with it.  Perhaps the most common type of lag is caused by network performance problems. Losses, corruption or jitter (an outdated packet is in effect a loss) may all cause problems, but these problems are relatively rare in network with sufficient bandwidth and no or little congestion. Instead, the latency involved in transmitting data between clients and server play a significant role. Latency varies depending on a number of factors, such as the physical distance between the end-systems, as a longer distance means additional transmission length and routing required and therefore higher latency. Routing over the Internet may be extremely indirect, resulting in far more transmission length (and consequential latency) than a direct route, although the cloud gaming service OnLive has developed a solution to this issue by establishing peering relationships with multiple Tier 1 network Internet Service Providers and choosing an optimal route between server and user. In addition, insufficient bandwidth and congestion, even if not severe enough to cause losses, may cause additional delays regardless of distance. As with the hardware issues, packets that arrive slowly or not at all will make both the client and server unable to update the game state in a timely manner.  Online game systems utilizing a wireless network may be subject to significant lag, depending on the architecture of the wireless network and local electromagnetic interference impacting that network. Although radio propagation through air is faster than light through optical fiber, wireless systems are often shared among many users and may suffer from latency incurred due to network congestion, or due to network protocols that introduce latency. And, in the event of electromagnetic interference, transmitted packets may be lost, requiring a retransmission which also incurs latency.

 

 

What are its Effects?

 

The noticeable effects of lag vary depending on the exact cause, but also on any and all techniques for lag compensation that the game may implement. As all clients experience some amount of delay, implementing these methods to minimize the effect on players is important for smooth gameplay. Lag causes numerous problems for issues such as accurate rendering of the game state and hit detection. In many games, lag is often frowned upon because it disrupts normal gameplay. The severity of lag depends on the type of game and its inherent tolerance for lag. Some games with a slower pace can tolerate significant delays without any need to compensate at all, where as others with a faster pace are considerably more sensitive and requires extensive use of compensation to be playable (most prevalent is probably the first-person shooter genre). Due to the various problems lag can cause, many players that have a lower speed Internet connection are often not permitted, or discouraged from playing with other players or servers that have a distant server host or have high latency to one another. Extreme cases of lag may result in extensive de-synchronization of the game state.

Lag caused by an insufficient update rate between client and server can cause some problems, but these are generally limited to the client itself. Other players may notice jerky movement and similar problems for the affected client, but the real problem lies with the client itself. If the client cannot update the game state at a quick enough pace, the player may be shown outdated renditions of the game, which in turn causes various problems with hit- and collision detection. If the low update rate is caused by a low frame rate (as opposed to a setting on the client, as some games allow), these problems are usually overshadowed by numerous problems related to the client-side processing itself. Both the display and controls will be sluggish and unresponsive. While this may increase the perceived lag, it is important to note that it is of a different kind than network-related delays. In comparison, the same problem on the server may cause significant problems for all clients involved. If the server is unable or unwilling to accept packets from clients fast enough and process these in a timely manner, client actions may never be registered. When the server then sends out updates to the clients, they may experience freezing (unresponsive game) and/or rollbacks, depending on what types of lag compensation, if any, the game uses.  Lag due to network delay is in contrast often less of a problem. Though more common, the actual effects are generally smaller, and it is possible to compensate for these types of delays. Without any form of lag compensation, the clients will notice that the game responds only a short time after an action is performed. This is especially problematic in first-person shooters, where enemies are likely to move as a player attempts to shoot them and the margin for errors is often small.

[Khaoios 1,970]

How to recover from Lags:

 

Client-Side:

As clients are normally not allowed to define the main game state, but rather receive it from the server, the main task of the client-side compensation is to render the virtual world as accurately as possible. As updates come with a delay and may even be dropped, it is sometimes necessary for the client to predict the flow of the game. Since the state is updated in discrete steps, the client must be able to estimate a movement based on available samples. Two basic methods can be used to accomplish this; extrapolation and interpolation.

Extrapolation is an attempt to estimate a future game state. As soon as a packet from the server is received, the position of an object is updated to the new position. Awaiting the next update, the next position is extrapolated based on the current position and the movement at the time of the update. Essentially, the client will assume that a moving object will continue in the same direction. When a new packet is received, the position may be corrected slightly.

Interpolation works by essentially buffering a game state and rendering the game state to the player with a slight, constant delay. When a packet from the server arrives, instead of updating the position of an object immediately, the client will start to interpolate the position, starting from the last known position. Over an interpolation interval, the object will be rendered moving smoothly between the two positions. Ideally this interval should exactly match the delay between packets, but due to loss and variable delay, this is rarely the case.

Both methods have advantages and drawbacks.

• Interpolation ensures that objects will move between valid positions only and will produce good results with constant delay and no loss. Should dropped or out-of-order packets overflow the interpolation buffer the client will have to either freeze the object in position until a new packet arrives, or fall back on extrapolation instead. The downside of interpolation is that it causes the world to be rendered with additional latency, increasing the need for some form of lag compensation to be implemented.
• The problem with extrapolating positions is fairly obvious: it is impossible to accurately predict the future. It will render movement correctly only if the movement is constant, but this will not always be the case. Players may change both speed and direction at random. This may result in a small amount of "warping" as new updates arrive and the estimated positions are corrected, and also cause problems for hit detection as players may be rendered in positions they are not actually in.

Often, in order to allow smooth gameplay, the client is allowed to do soft changes to the game state. While the server may ultimately keep track of ammunition, health, position etc., the client may be allowed to predict the new server-side game state based on the player's actions, such as allowing a player to start moving before the server has responded to the command. These changes will generally be accepted under normal conditions and make delay mostly transparent. Problems will arise only in the case of high delays or losses, when the clients predictions are very noticeably undone by the server. Sometimes, in the case of minor differences, the server may even allow "incorrect" changes to the state based on updates from the client.

 

Server-Side:

Unlike clients the server knows the exact current game state, and as such prediction is unnecessary. The main purpose of server-side lag compensation is instead to provide accurate effects of client actions. This is important because by the time a player's command has arrived time will have moved on, and the world will no longer be in the state that the player saw when issuing their command. A very explicit example of this is hit detection for weapons fired in first-person shooters, where margins are small and can potentially cause significant problems if not properly handled.

 

Do nothing

One potential "solution" is to simply ignore the problem. For hit detection in first-person shooters this means leading one's target, aiming at the position where it will be by the time the shot reaches the server. With variable latency this may be frustrating even under ideal conditions; with higher latency and random player movement it can make playing virtually impossible. For example, if a remote player passes by a window in a period shorter than the client's latency it will be impossible for the local player to hit them even if they fire immediately.  However, doing nothing does have the advantage of giving players the truest possible picture of what is happening to their input. In games where the player can only exert indirect control, such as RTS games, it is considered acceptable for the local player's troops to be lagged as long as his or her direct inputs (typically cursor position, unit selection, and camera position) are responsive.

 

Rewind time

Another way to address the issue is to store past game states for a certain length of time, then rewind player locations when processing a command.The server uses the latency of the player (including any inherent delay due to interpolation; see above) to rewind time by an appropriate amount in order to determine what the shooting client saw at the time the shot was fired. This will usually result in the server seeing the client firing at the target's old position and thus hitting. In the worst case a player will be so far behind that the server runs out of historic data and they have to start leading their targets.

This is a WYSIWYG solution that allows players to aim directly at what they are seeing. But the price is an aggravation of the effects of latency when a player is under fire: not only does their own latency play a part, but their attacker's too. In many situations this is not noticeable, but players who have just taken cover will notice that they carry on receiving damage/death messages from the server for longer than their own latency can justify. This can lead more often to the (false) impression that they were shot through cover and the (not entirely inaccurate) impression of "laggy hitboxes".  One design issue that arises from rewinding is whether to stop rewinding a dead player's lagged commands as soon as they die on the server, or to continue running them until they "catch up" to the time of death. Cutting compensation off immediately prevents victims from posthumously attacking their killers, which meets expectations, but preserves the natural advantage of moving players who round a corner, acquire a target and kill them in less time than a round trip to the stationary victim's client.

Rewinding can be criticised for allowing the high latency of one player to negatively affect the experience of low-latency players. Servers with lag compensation will sometimes reduce the length of player history stored, or enforce ping limits, to reduce this problem.

 

Trust clients

It is possible for clients to tell the server what they are doing and for the server to trust the data it receives. This method is avoided if at all possible due to its susceptibility to cheating: it is a simple matter to route network data through a second computer which inserts fabricated hit messages or modifies existing ones, a technique which cannot be detected by anti-cheat tools. However, the sheer scale of some games makes computationally expensive solutions like rewinding impossible. In Battlefield 3, for example, a "hybrid hit detection" system is used where clients tell the server that they hit and the server performs only a vague test of plausibility before accepting the claim.Trusting a client's results otherwise has the same advantages and disadvantages as rewinding.

 

Make clients extrapolate

A less common lag solution is to do nothing on the server and to have each client extrapolate (see above) to cover its latency. This produces incorrect results unless remote players maintain a constant velocity, granting an advantage to those who dodge back and forth or simply start/stop moving.

Extended extrapolation also results in remote players becoming visible (though not vulnerable) when they should not be: for example if a remote player sprints up to a corner then stops abruptly at the edge, other clients will render them sprinting onward, into the open, for the duration of their own latency. On the other side of this problem, clients have to give remote players who just started moving an extra burst of speed in order to push them into a theoretically-accurate predicted location.

 

Design

It is possible to reduce the perception of lag through game design. Techniques include playing client-side animations as if the action took place immediately, reducing/removing built-in timers on the host machine, and using camera transitions to hide warping.

[Khaoios 1,970]

UPDATE: Adding Preventions Lists.......