56 lines
3.3 KiB
HTML
56 lines
3.3 KiB
HTML
<!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>
|
|
<li>Client and server shares code, requiring security checks on the server's side which are too easy to miss</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>
|
|
<li>Make client and server code as isolated from each other as possible</li>
|
|
</ul>
|
|
<h2>How new netcode will work</h2>
|
|
<h3>Authentication</h3>
|
|
Login encryption consists of sending a hash of hashed password with the nonce appended.
|
|
<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> - juan
|
|
</body>
|
|
</html> |