Open 2bdkid opened 3 years ago
Ok I figured it out. The rd keeps track based on (ep, d) and the ip:port has nothing to do with the issue. I added an ep in the registration_parameters of each Registerer and that fixed the issue. Reading through the code, the ep was being set through fqdn and that would have been the same because I'm running 2 instances on the same host. That's why the rd thought it was a re-register.
Thanks for reporting this; reopening as just because clients behave oddly, the RD server should still not spitting out KeyError messages.
(What really should have happened would be the clients flip-flopping the address of the registered item back and forth between their ports -- although on a more to-the-spec level, really the RD should ask at least some level of security from the endpoint).
I'm running into an issue registering some resources with aiocoap-rd. In the first instance of my server program, I create a context and bind to a specified port, and then do the registration:
This registration goes through just fine:
Then, I start another instance of my server on the same host (I think this may be the problem), but bind to a different port:
After a second, aiocoap-rd spits this out:
Then, the second server instance receives an error 500 from rd.
Interestingly, if I start the second instance again, its registration goes through, but the first server instance's registration is lost. Lost as in it's no longer sent back when queried from coap://localhost/resource-lookup/.
It seems like aiocoap-rd is getting confused by having a registration from the same ip, but with different ports.