rns.recipes

Subject: BackboneInterface hub under load: listen(1) backlog and repeated announce signature checks Setup: RNS 1.5.7, public transport node on a 2 vCPU VPS, BackboneInterface listeners on two ports with ~~500 connected clients, plus 4 outgoing backbone peers. rnstatus -A shows ~~107 Hz of incoming announces on the main listener (about 0.2 Hz per client). 1) BackboneInterface uses server_socket.listen(1). When the single __job thread is busy, new incoming connections beyond the first pending one are dropped, so clients (Android, Windows) fail to connect or time out while existing connections keep working. Changing it locally to listen(128) fixed this immediately. Could the backlog be raised or made configurable? (Same idea for TCPServerInterface: ThreadingTCPServer inherits request_queue_size = 5.) 2) Most of the __job thread time is spent on announce signature checks. py-spy samples taken during lag spikes (5 s apart) show the __job thread in validate_announce in every sample: ed25519 verify <- Identity.validate (Identity.py:939) load_public_key <- validate_announce (Identity.py:551) preprocess_inbound (Transport.py:1806) Meanwhile unread data waits in the socket receive queues (120-750 KB), and the lag (up to ~16 s) is felt by every application on the node. Network to the VPS was measured as fine (TCP connect 55 ms avg, no failures). As far as I can see, duplicate SINGLE announces are intentionally let through packet_filter (for path/hop logic), and each copy gets its signature verified again. load_public_key also runs twice per announce (preprocess_inbound and _inbound). Would it make sense to cache verification results for identical announces? Note that packet_hash masks the flags byte to the low 4 bits, so context_flag (ratchet present) is not covered; a cache keyed only on packet_hash would be unsafe. It would need to cover the full announce content including that bit. Happy to provide more py-spy dumps or test a patch.