Welcome aboard Visitor...

Daily Screenshot

Server Costs Target


84% of target met.

Latest Topics

- so i talked with Massi »
- See Commands »
- Now the fun begins »
- Qand answers have returned »
- Call to Arms »
- All Species 8572 Report in »
- hi there »
- Anyone still playing from a decade ago or longer? »
- Game still active. NICE! »
- help me »

Development Blog

- Roadmap »
- Hello strangers, it’s been a while... »
- State of DarkSpace Development »
- Potential planetary interdictor changes! »
- The Silent Cartographer »

Combat Kills

Combat kills in last 24 hours:
No kills today... yet.

Upcoming Events

- Weekly DarkSpace
11/23/24 +21.0 Hours

Search

Anniversaries

No anniversaries today.

Social Media

Why not join us on Discord for a chat, or follow us on Twitter or Facebook for more information and fan updates?

Network

DarkSpace
DarkSpace - Beta
Palestar

[FAQ
Forum Index » » General Support » » desync ? what is it ?
 Author desync ? what is it ?
NoBoDx
Grand Admiral

Joined: October 14, 2003
Posts: 784
From: Germany / NRW
Posted: 2010-09-27 14:24   
desync ? what is it ?

you are out-of-sync (de-sync-ed) when data from the server haven't reached your client, but neither the server, nor the client recognize it.

why is it happening ( or why had it happened before )?

the normal, standard transfer-protocol for data over the internet is TCP
those interested in details, can check the link from wikipedia, but here just the basics:
- two persons (-=A=- and -=B=-) (or computers): -=A=- send the numbers 1 - 5 to -=B=-

-- -=A=- send 1 to -=B=-
-- -=B=- recive 1 (-=A=- dont know, if -=B=- got it, or not)
-- -=B=- send -=A=- a confirmation
-- -=A=- recive the confirmation (and know -=B=- recieved the 1)
-- -=A=- send -=B=- a confirmation (-=B=- knows, that -=A=- recieved the confirmation)

-- -=A=- send 2 to -=B=-
-- -=B=- does not recive 2 (-=A=- dont know, if -=B=- got it, or not)
-- after some time -=A=- decide to resend 2 because it didnt get a confirmation from -=B=-
-- -=B=- recive 2 (-=A=- dont know, if -=B=- got it, or not)
-- -=B=- send -=A=- a confirmation
-- -=A=- recive the confirmation (and know -=B=- recieved the 1)
-- -=A=- send -=B=- a confirmation (-=B=- knows, that -=A=- recieved the confirmation)

this is done for each packet

because of the many packets + 2 confirmations the traffic is quite high, but reliable, because -=A=- keep sending each packets, until it is sure, -=B=- recieved it (confirmations are also resend until -=B=- recieve the confirmation from -=A=-)

the final numbers would be 1-2-3-4-5

for ds:
your client might be frozen but the commands will be resend till both know, they reached their target
the result may be like this:
- you press space, but nothing happens
- after a while your client recieve the confirmation and he continue with the orders sent by the server (e.g. your target flew trough you in the meantime resulting in a very fast ship, running at high-speed through you)

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

UDP:
-=A=- send 1 to -=B=-
-=A=- send 2 to -=B=- without waiting for a confirmation from -=B=-
-=A=- send 3 to -=B=- without waiting for a confirmation from -=B=-
-=A=- send 4 to -=B=- without waiting for a confirmation from -=B=-
-=A=- send 5 to -=B=- without waiting for a confirmation from -=B=-

but

-=B=- have a bad internet-connection with high packet-loss, so:
-=B=- recieve 1 from -=A=-
-=B=- recieve 3 from -=A=-
-=B=- recieve 5 from -=A=-

this way, the final numers would be (only) 1-3-5

because -=B=- dont have to confirm every package from -=A=- and -=A=- dont have to confirm every confirm from -=B=- data can be send much faster than with tcp
BUT when the connection have a high package-lost, some (or many...) packaged arent recieved by the other one ( maybe your e-jump-command, or the hit from the QST, or the turn-command in front of a planet...) resulting in a de-synchronisation between the server and the client (and neither one even know it)

*first version... have to check spelling/formating/logical errors
** im fine with it for now
[ This Message was edited by: NoBoDx on 2010-09-27 14:35 ]
_________________
The only good 'ooman is a dead 'ooman. An' da only fing better than a dead 'ooman'z a dyin' 'ooman who tell you where ter find 'is mates.

BackSlash
Marshal
Galactic Navy


Joined: March 23, 2003
Posts: 11183
From: Bristol, England
Posted: 2010-09-27 14:43   
Desync is when your client thinks the enemy is at 50% hull and the server states the enemy is at 100%. The client will not realise this, and won't correct the data. This is desync.
_________________


-Shadowalker-™
Admiral
Galactic Navy


Joined: September 23, 2007
Posts: 709
From: Shadows
Posted: 2010-09-27 14:49   
Quote:

On 2010-09-27 14:43, BackSlash wrote:
Desync is when your client thinks the enemy is at 50% hull and the server states the enemy is at 100%. The client will not realise this, and won't correct the data. This is desync.




I dont even respect that as a response... i mean really, thats the best you could come up with....
_________________


  Email -Shadowalker-™
Vice Admiral Josh Knight
Vice Admiral

Joined: July 25, 2010
Posts: 56
Posted: 2010-09-27 19:26   
Quote:

On 2010-09-27 14:49, -Shadowalker-™ wrote:
Quote:

On 2010-09-27 14:43, BackSlash wrote:
Desync is when your client thinks the enemy is at 50% hull and the server states the enemy is at 100%. The client will not realise this, and won't correct the data. This is desync.




I dont even respect that as a response... i mean really, thats the best you could come up with....





Isn't what backslash said EXACTLY what it is? No need to get complicated when his answer is perfectly fine.
_________________


  Email Vice Admiral Josh Knight
Page created in 0.008148 seconds.


Copyright © 2000 - 2024 Palestar Inc. All rights reserved worldwide.
Terms of use - DarkSpace is a Registered Trademark of PALESTAR