nsg-ethz / autopower

A software suite to conveniently collect, gather, and display power measurement from networking hardware.
MIT License
2 stars 1 forks source link

Save IP of autopower client in DB #26

Open UsualSpec opened 1 week ago

UsualSpec commented 1 week ago

Somewhat related: why do we send a request to the client in order to get the IP? Why not simply save the IP in the database when the client registers to the server? Sounds like it would be a lot simpler, no?

And if the IP changes, the client would anyway register again to the server I suppose, since changing IP address (almost always) implies we lost network connectivity. Or am I missing something?

Originally posted by @romain-jacob in https://github.com/nsg-ethz/autopower/issues/24#issuecomment-2363569830

UsualSpec commented 1 week ago

The main reason was that saving the IP in the DB is redundant and could become outdated. Therefore the IP address attributes (along with others) was removed from the schema in https://github.com/nsg-ethz/autopower/commit/a7f7e4873120a93f13183067106d860ac9f7cc96

We decided that getting the IP directly from the device in the UI would be a better choice as it's always up to date.

UsualSpec commented 1 week ago

It would be possible to retrieve the IP like in https://github.com/nsg-ethz/autopower/blob/1911af784f3ebd97050e28a316931f3fd56d8f28/server/server.py#L359-L363

Then save the IP e.g. in https://github.com/nsg-ethz/autopower/blob/1911af784f3ebd97050e28a316931f3fd56d8f28/server/server.py#L338

romain-jacob commented 1 week ago

I'm not entirely sure what would happen to the gRPC connection if the client IP changes. Would it survive the change? Because if not, then I don't see why would need to collect the IP in a server request; we can just get it when the client registers, as it would need to re-register if the IP changes.

... unless, in some magical way I don't understand, the gRPC connection survives the client getting a new IP?

UsualSpec commented 1 week ago

I believe that currently a client side change would mean that a new connection gets established. However, if gRPC uses QUIC/HTTP3 in future I could imagine that the connection stays active (QUIC connection migration; https://www.rfc-editor.org/rfc/rfc9000.html#section-5-4). See also https://kmcd.dev/posts/grpc-over-http3/