From 3d1cb65330b40edd01fc8f3d4f13277bcafbfb02 Mon Sep 17 00:00:00 2001
From: juanjp600 <juanjp@live.com>
Date: Wed, 31 Aug 2016 20:58:01 -0300
Subject: [PATCH] Added design plan

Here's a basic outline of what this is going to be, not a really in-depth explanation.
---
 NETCODE REWRITE DESIGN PLAN.html | 54 ++++++++++++++++++++++++++++++++
 1 file changed, 54 insertions(+)
 create mode 100644 NETCODE REWRITE DESIGN PLAN.html
diff --git a/NETCODE REWRITE DESIGN PLAN.html b/NETCODE REWRITE DESIGN PLAN.html
new file mode 100644
index 000000000..e13b7e4ef
--- /dev/null
+++ b/NETCODE REWRITE DESIGN PLAN.html	
@@ -0,0 +1,54 @@
+<!DOCTYPE html>
+<html>
+<head>
+<title>Netcode Rewrite Design Plan</title>
+<style>
+body {
+	font-family: Tahoma;
+}
+</style>
+</head>
+<body>
+<h1>NETCODE REWRITE DESIGN PLAN</h1>
+<h2>Problems with current netcode</h2>
+<ul>
+<li>Packet rate is a bit too high</li>
+<li>Heavy use of reliable channel</li>
+<li>Hacking is really easy</li>
+<li>Lag is really hard to hide</li>
+<li>It'll eventually be unusable because of new stuff being added</li>
+</ul>
+<h2>Goals of rewrite</h2>
+<ul>
+<li>Greatly reduce use of reliable channel, preferring redundancy instead</li>
+<li>Authoritative server; less hacking</li>
+<li>More secure code</li>
+<li>Maybe better interpolation; make lag less noticeable</li>
+</ul>
+<h2>How new netcode will work</h2>
+<h3>Authentication</h3>
+Login encryption will be essentially the same as it is now. Hash of hashed password + nonce.
+<br>
+<br>Authentication will be split into two steps:
+<ul>
+<li><b>Auth Request: </b>Clients don't know whether they need to use a password until the server tells them. Instead of making the client send an incorrect login packet and bring up a login box after the fact, get them to ask the server first.
+<br>Server will tell the player if they need a password, in that case they'll be given the random Nonce integer for encryption.</li>
+<li><b>Init Request: </b>Once the auth request goes through, the client will need to send the password with encryption, or will just login automatically if it isn't required.<br>
+If the client sends an incorrect password, rather than immediately closing the connection, the server will give the client a few chances to retry.<br>
+If a client connects with the same name as an existing client and has the same IP as it, server will assume the old connection is dead and replace it.</li>
+</ul>
+
+<h3>Syncing data</h3>
+Rather than sending data (chat messages, character inputs, etc) with Lidgren's reliability, changes are stacked on each peer's side and given IDs.
+<br>Each peer will tell the other which was the last ID they got. The other peer will send all messages in their stack that are newer than that ID.
+<br>If a peer gets data that it already has, it'll discard it. The other peer will eventually know that it has to stop sending this data.
+<br>
+<br>In the case of player input, the server will freeze each character until it receives input. Once it does, it'll move the player accordingly.
+<br>Clients <i>WILL NOT</i> send positions to the server. Instead, they'll send a queue with inputs from the last frames that haven't been synced, with a limit of about 100 inputs or so.
+<br>Since server will be receiving all inputs from the player, a normal client should not have too much desyncing if their connection is good enough.
+<br>Server will send each client their own positions, because that's the server's decision, not the client's. The client will remember its last 100 predicted positions, so when it receives this data from the server it'll compare with old data and compensate only if there's a big enough difference with that old position.
+<br>
+<br>If none of this makes sense, ask me on Discord and I'll reply whenever I'm on.
+<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;- juan
+</body>
+</html>
\ No newline at end of file
