upleb.uk

Public git repos — served from a NIP-34 GRASP relay at git.upleb.uk

summaryrefslogtreecommitdiff
path: root/src/btfrv.cpp
diff options
context:
space:
mode:
authorBitflash <btf01@proton.me>2026-07-29 13:28:50 -0300
committerGitHub <noreply@github.com>2026-07-29 13:28:50 -0300
commit997e511e120272e8f2ddd29716b486e597410f02 (patch)
tree42c816df51d837bcac9f806864d677c2d9a9de0c /src/btfrv.cpp
parent6e836ed5cb5f41391e335b4f508dc6c0e8915ba5 (diff)
rendezvous: register and wait for a dial as separate steps (#30)
A node could not become reachable. RvServiceRegister connected, sent its 'S'+pubkey header, and then blocked reading the relay's 0x01 byte -- which the relay only writes when a client pairs with the service. So the call did not return when the node was registered; it returned when somebody had already dialled it. ThreadBtfAccept called BtfSetActiveRelay after that. The result is a deadlock: - to be dialled, a node must publish a descriptor naming its meeting node - to publish, BtfActiveRelay() must be set - it is only set once somebody has dialled Before #26 this was masked. BtfActiveRelay() fell back to vBtfMeetingRelays[0], so a node always published something, and ThreadBtfAccept picks its relay at random -- so it worked whenever the two happened to match, roughly one time in the number of relays. That is the flakiness this project has been chasing: not a bad relay, an advertisement that usually named the wrong one. #26 removed the fallback, which was right on its own terms and turned an unreliable heuristic into a reliable deadlock. This is the other half of that change and they belong together. RvServiceRegister now returns as soon as the relay has the service listed. RvServiceWaitPaired does the blocking read. ThreadBtfAccept registers, advertises, then waits. RvClientConnect is untouched -- a dialer blocking until it is paired is correct. Registration failure also had no log line at all, which is why this stayed invisible: a node that never registered looked identical to one waiting quietly for a peer. There are now lines for registering, failing over, and being dropped. Verified: a fresh node reports `registered at 90.156.222.107:8434, waiting for a dial` and then self-resolves with `meeting_node=90.156.222.107:8434` -- the relay it is actually on. Two nodes on one machine reach each other.
Diffstat (limited to 'src/btfrv.cpp')
-rw-r--r--src/btfrv.cpp13
1 files changed, 11 insertions, 2 deletions
diff --git a/src/btfrv.cpp b/src/btfrv.cpp
index 0d02ca8..63e092e 100644
--- a/src/btfrv.cpp
+++ b/src/btfrv.cpp
@@ -250,11 +250,20 @@ RvSocket RvServiceRegister(const char* relay_host, unsigned short port,
250 hdr[0] = (unsigned char)'S'; 250 hdr[0] = (unsigned char)'S';
251 memcpy(hdr + 1, my_pubkey, 32); 251 memcpy(hdr + 1, my_pubkey, 32);
252 if (!WriteN(s, hdr, 33)) { CLOSESOCK(s); return RV_INVALID; } 252 if (!WriteN(s, hdr, 33)) { CLOSESOCK(s); return RV_INVALID; }
253 unsigned char paired = 0; 253 // Return here: registered, not yet paired. The relay lists the service as
254 if (!ReadN(s, &paired, 1) || paired != 0x01) { CLOSESOCK(s); return RV_INVALID; } 254 // soon as it reads this header. The 0x01 that used to be consumed below
255 // only arrives when somebody dials us, so blocking on it made "registered"
256 // and "already in use" indistinguishable to the caller -- and left the node
257 // unable to advertise a meeting node until after it had been reached there.
255 return (RvSocket)s; 258 return (RvSocket)s;
256} 259}
257 260
261bool RvServiceWaitPaired(RvSocket s)
262{
263 unsigned char paired = 0;
264 return ReadN((SOCKET)s, &paired, 1) && paired == 0x01;
265}
266
258RvSocket RvClientConnect(const char* relay_host, unsigned short port, 267RvSocket RvClientConnect(const char* relay_host, unsigned short port,
259 const unsigned char target_pubkey[32]) 268 const unsigned char target_pubkey[32])
260{ 269{