CodeMirror/xpipe
1
0
Fork 0
mirror of https://github.com/xpipe-io/xpipe.git synced 2024-06-24 17:10:19 +12:00
Code Issues Packages Projects Releases Wiki Activity

[release]

Browse source
This commit is contained in:
crschnick 2024-01-20 19:06:57 +00:00
parent ebc1f33a56
commit 809999394d
3 changed files with 40 additions and 12 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

16
dist/changelogs/1.7.16.md vendored
View file

@ -3,25 +3,19 @@
Over time, there have always been a few complaints about SSH connection timeout errors and slow SSH connection startup. These especially popped up in the latest release even though no obvious code was changed.
As it turns out, increasing the value for `ConnectTimeout` in SSH does not actually only change the timeout after which an error is thrown, it is also used by some servers as a guideline for their response time.
E.g. if you specify a 10s timeout, some servers will always take 10s to respond.
This is of course not mentioned in any of the spec but is more of an implementation choice.
As it turns out, increasing the value for `ConnectTimeout` in SSH does not actually only change the timeout after which an error is thrown, it is also used by some servers as a guideline for their response time. E.g. if you specify a 10s timeout, some servers will always take 10s to respond. This is of course not mentioned in any of the spec but is more of an implementation choice.
In the latest release this caused more errors as the timeout was set higher.
It should also have affected many SSH connections basically since the release of XPipe.
I don't know how many people have been affected by this, it heavily depends on which ssh server and configuration your server runs.
It happens for example on my proxmox instances and my AWS EC2 instances.
In the latest release this caused more errors as the timeout was set higher. It should also have affected many SSH connections basically since the release of XPipe. I don't know how many people have been affected by this, it heavily depends on which ssh server and configuration your server runs. It happens for example on my proxmox instances and my AWS EC2 instances. If your connections now start up much faster than before, then you are probably affected by it.
This release should fix all of these issues simply by not specifying a connect timeout at all. Great work there.
This release should fix all of these issues simply by not specifying a connect timeout at all. Great work there. If you are using `ConnectTimeout` in your SSH configs, just remove it as it makes everything slower without having the effect of a timeout.
I would like to exchange a few words with whoever thought: *A newly connected SSH client specified a 10s connect timeout? That means we can sit around idle for 9 seconds. That is a great idea.*
Load balancing my ass, this also happens if the system is completely idle.
## Fixes
- Fix annoying log directory errors that occurred on first startup
- Fix SSH connections failing on Windows systems where the username contained non-ASCII characters
due to an OpenSSH client bug by working around it
- Fix SSH connections failing on Windows systems where the username contained non-ASCII characters due to an OpenSSH client bug by working around it
- Fix SSH connection failing when another RemoteCommand was set in a config file
- Fix child connection validity not updating when parent is changed from invalid to valid
- Fix some applications launched on Windows, e.g. some terminals and editors, starting in minimized mode
- Fix SSH config importer not handling file wildcards correctly when they also contained a file extension

34
dist/changelogs/1.7.16_augmented.md vendored Normal file
View file

@ -0,0 +1,34 @@
## SSH Timeouts and connection time
Over time, there have always been a few complaints about SSH connection timeout errors and slow SSH connection startup. These especially popped up in the latest release even though no obvious code was changed.
As it turns out, increasing the value for `ConnectTimeout` in SSH does not actually only change the timeout after which an error is thrown, it is also used by some servers as a guideline for their response time. E.g. if you specify a 10s timeout, some servers will always take 10s to respond. This is of course not mentioned in any of the spec but is more of an implementation choice.
In the latest release this caused more errors as the timeout was set higher. It should also have affected many SSH connections basically since the release of XPipe. I don't know how many people have been affected by this, it heavily depends on which ssh server and configuration your server runs. It happens for example on my proxmox instances and AWS EC2 instances. If your connections now start up much faster than before, then you were probably affected by it.
This release should fix all of these issues simply by not specifying a connect timeout at all. Great work there.
If you are using `ConnectTimeout` in your SSH configs, just remove it as it makes everything slower without having the effect of a timeout.
I would like to exchange a few words with whoever thought: *A newly connected SSH client specified a 10s connect timeout? That means our SSH server can sit around idle for 9 seconds. That is a great idea.*
## Fixes
- Fix annoying log directory errors that occurred on first startup
- Fix SSH connections failing on Windows systems where the username contained non-ASCII characters due to an OpenSSH client bug by working around it
- Fix SSH connection failing when another RemoteCommand was set in a config file
- Fix child connection validity not updating when parent is changed from invalid to valid
- Fix some applications launched on Windows, e.g. some terminals and editors, starting in minimized mode
- Fix SSH config importer not handling file wildcards correctly when they also contained a file extension
- Fix actions that shut down XPipe, e.g. automatic updates and debug mode, not correctly executing if it exited too fast
- Fix error about nonexistent logs directory on first startup
- Fix possible NullPointers when checking whether current SSH session has died
## Error reporter
It seems like the current built-in error reporter service is broken right now, so I might not receive your written user feedback from it.
If you want to report any issues, please use another way until that is fixed.
## Previous changes in 1.7.15
- [1.7.15 changelog](https://github.com/xpipe-io/xpipe/releases/tag/1.7.15)

2
version
View file

@ -1 +1 @@
1.7.16-2
1.7.16