74 lines
2.4 KiB
Markdown
74 lines
2.4 KiB
Markdown
|
# PTTH_DIREC - Direct P2P connections
|
||
|
|
|
||
|
|
_It could work, even!_
|
||
|
|
|
||
|
|
To keep each ridiculous new feature simple, we'll rely on bootstrapping:
|
||
|
|
|
||
|
|
1. PTTH is just HTTPS connections
|
||
|
|
2. PTTH_QUIC uses a PTTH relay to download the QUIC cert and bootstrap
|
||
|
|
3. PTTH_DIREC will use a PTTH_QUIC relay to bootstrap
|
||
|
|
|
||
|
|
# Overview
|
||
|
|
|
||
|
|
Given that:
|
||
|
|
|
||
|
|
- P2 is connected to P3
|
||
|
|
- P4 is connected to P3
|
||
|
|
|
||
|
|
Steps:
|
||
|
|
|
||
|
|
- S1. P2 starts a bi stream to P3
|
||
|
|
- S2.0. P2 says, "I want to initiate a PTTH_DIREC connection..."
|
||
|
|
- "... And I'll send you cookie X to do hole-punching..."
|
||
|
|
- "... And I want to connect to end server Y..."
|
||
|
|
- S3.0. P3 creates an ID for this connection
|
||
|
|
- S3.1. P3 replies "go ahead" to P2
|
||
|
|
- S4. P3 starts a bi stream to P4 (end server Y)
|
||
|
|
- S5. P3 says, "I want you to accept a PTTH_DIREC connection..."
|
||
|
|
- "... And you should send me cookie Z to do hole-punching..."
|
||
|
|
- "... And the client will be client W..."
|
||
|
|
- S6. P3 waits for P4 to accept the offer
|
||
|
|
- S7. P3 waits for both cookies to arrive
|
||
|
|
- S8. When the cookies arrive, P3 learns the WAN addresses of P2 and P4
|
||
|
|
- S9. P3 sends the WAN addresses of P2 and P4 to each other (on the existing bi streams)
|
||
|
|
- S10. P4 tries to connect directly to P2
|
||
|
|
- S11. P2 does the same to P4
|
||
|
|
- S12. When P4 sees round-tripped data, it attempts to upgrade to QUIC
|
||
|
|
- S13. When P2 sees round-tripped data, it attempts to upgrade to QUIC
|
||
|
|
- Cool stuff happens over QUIC
|
||
|
|
- ReactorScram implements the rest of the protocol
|
||
|
|
|
||
|
|
P2's PoV:
|
||
|
|
|
||
|
|
- S1. Start a bi stream to P3
|
||
|
|
- S2.0. Send cookie and server ID
|
||
|
|
- S2.1. Wait for go-ahead signal (this may contain the hole-punch address and a new cookie for P4)
|
||
|
|
- S2.2. Send cookie to hole-punch address repeatedly
|
||
|
|
- S2.3. While you're sending the cookie, wait to hear P4's WAN address
|
||
|
|
- S9. Learn P4's WAN address
|
||
|
|
- S10. Send the new cookie to P4's address
|
||
|
|
- S12. When you see round-tripped data, upgrade to QUIC
|
||
|
|
|
||
|
|
P4's PoV:
|
||
|
|
|
||
|
|
- S4. Accept a bi stream from P3
|
||
|
|
- S5. Receive cookie and client ID
|
||
|
|
- S6. Reply "OK"
|
||
|
|
- S7.0. Send cookie to hole-punch address repeatedly
|
||
|
|
- S7.1. While sending the cookie, wait to hear P2's WAN address
|
||
|
|
- S9. Learn P2's WAN address
|
||
|
|
- S10. Try to connect directly to P2
|
||
|
|
- S12. When you see round-tripped data, upgrade to QUIC
|
||
|
|
|
||
|
|
Commands needed:
|
||
|
|
|
||
|
|
- ???
|
||
|
|
|
||
|
|
# Decisions
|
||
|
|
|
||
|
|
I'll add a delay between giving P2's address to P4, and giving P4's address to P2.
|
||
|
|
This miiiight change things slightly if P4's firewall is suspicious of packets
|
||
|
|
coming in too early, but I doubt it.
|
||
|
|
|
||
|
|
The delay is easy to remove relay-side if it doesn't help.
|