neale/vail
neale
/
vail
mirror of https://github.com/nealey/vail.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Created Geek Stuff (markdown)

Neale Pickett 2022-04-24 17:05:32 -06:00
parent 3ba2371201
commit 56270919ec
1 changed files with 12 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
Geek-Stuff.md Normal file

@ -0,0 +1,12 @@
The Internet isn't exactly like radio waves: it still goes at near the speed of light, but there are multiple hops between endpoints, which buffer up transmissions, and multiplex them onto a single uplink connection. These repeaters (routers) are also allowed to just drop things if they need to. It's the responsibility of the communicating parties to work out whether something needs to be retransmitted. Because of this, there's no telling how long it will take for a transmission to get to a destination.
Each Vail transmission (packet) consists of:
* timestamp (milliseconds since 1 Jan 1970, 00:00:00 in Reykjavík)
* transmission duration (milliseconds)
The repeater does nothing but broadcast everything it gets to every connected Vail client, including the one that sent the packet. When your client gets back the exact same thing it sent, it compares the current time to the time in the packet. This is the round-trip time: the time it takes for a packet to get from your computer to the repeater and back.
When the client gets a packet it didn't send, it adds the receive delay to the timestamp, and schedules to play the tones and silences in the packet at that time.
By adding the maximum round-trip time to the longest recent transmission (the length of a dah, hopefully), your client can make a guess about how much time needs to be added to a received timestamp, in order to have it play back in the future at the time it comes in. This is just a guess. If you're communicating with somebody with a higher round-trip time than you have, you'll need to raise your receive delay to account for it.