Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature Request] General improvements for NYM nodes components when they are experiencing issues #3719

Open
twofaktor opened this issue Jul 29, 2023 · 1 comment
Labels
enhancement New feature or request needs-triage

Comments

@twofaktor
Copy link
Contributor

twofaktor commented Jul 29, 2023

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 attempts Starting proxy for...

spaces_PwUXd13GpYIkFW2A1Gwj_uploads_git-blob-997f8db52777704ed274eb4d630e1fc35cc26495_troubleshooting

Issue related: #4109

@twofaktor twofaktor added enhancement New feature or request needs-triage labels Jul 29, 2023
@Lorex-ia
Copy link
Contributor

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 :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request needs-triage
Projects
None yet
Development

No branches or pull requests

2 participants