Lorex-ia
commented
11 months ago Hey @twofaktor ! Thanks for raising this issue. Generally speaking, connecting to a few gateways as possible is meant to preserve anonymity but if the gateway is unreliable we understand this causes frictions for users. Strategically however, we currently prioritize privacy over ease of use... Considering options such as implementing a fallback gateway is an option - but this will undoubtedly impact privacy. We'll continue to think on the best way forth and will keep you in the loop :)
Is your feature request related to a problem?
NYM Network nodes (network requesters, SOCKS5 client, etc.) should automatically reconnect to another gateway if the current gateway's connection drops or encounters issues.
Currently, most gateways change frequently, as new ones appear, others that are currently in use, have occasional outages or are permanently disconnected, which causes inconveniences for other nodes connected to them, leaving them completely out of service.
Almost every day, I have to restart my network requester and consequently, all the SOCKS5 clients connected to it manually, and other times, only the SOCKS5 clients, as they may be the components left stranded due to the loss of their gateway. Similarly, in the case of the SOCKS5 client, it is very difficult to detect if the problem is from the network requester to which it is connected or from the gateway. This is because they do not show in their logs the real reason for the malfunction; they just do not display logs of the type:
nym_client_core::client::received_buffer > received plain 0.08 kiB message.It would also be great if the logs were more descriptive when the node is experiencing any type of problem and the reason behind it. For instance, in the case of the SOCKS5 client, the issue could be related to the service provider it is connected to or the gateway it is using. For the service provider (network requester), the issue would be related to the gateway only. However, the logs should still provide information about when and why these problems are occurring. If the automatic resolution is not yet implemented, the logs should provide a clear indication of the issue and suggest a possible manual fix to it.
What is this solving?
This can achieve greater stability of the NYM network overall and provide a better user experience.
Describe alternatives you've considered
Descriptive logs when something fails in a node, manual fix suggestion, automatic reconnection to another gateway, when the gateway is having problems or falls permanently, always prioritizing the best reputation, or simply a complete and automatic restart of the service if that's all that is needed.
Additional context
This is an example of a socks5 client having issues, the only way to detect it is because these logs don't appear:
nym_client_core::client::received_buffer > received plain 0.08 kiB message, and it shows only connection attemptsStarting proxy for...Issue related: https://github.com/nymtech/nym/issues/4109