Global Feed Post Login
Replying to Avatar Anthony Accioly

I’m doing the same. The real problem is telling apart flakey or temporarily down relays from ones that are actually dead. E.g, if I treat “fail to connect during startup” as dead, I risk missing relays that are just temporarily offline, which can be catastrophic for long-running processes like relays. But if I don’t, then I need increasingly complex retry algorithms (“penalty box”, exponential backoff, etc.), which still wastes time and resources retesting truly dead relays. Even worse, some dead relays just hang connections. Right now I’m using a 5-second timeout when testing relays, and even that adds up quickly when combined with retry algorithms across thousands of relays. A good blacklist would be very useful.

Avatar
Vitor Pamplona 4mo ago

You can also check for HTTP status codes when opening the connection. Many relays are offline and sending 400 and 500 codes. Those you can re-test once a day or so.

Reply to this note

Please Login to reply.

Discussion

Avatar
sandwich 4mo ago

Significnatly less efficient than NIP-66

Thread collapsed