@jks Remarks about the new proxy load balancer for proxy.kiwisdr.com servers.
I have spent quite some time developing a new socket connection method to support the load balancer. What I have noticed is that the connection to proxy.kiwisdr.com significantly slows down by the load balancer. For servers that are redirected to proxy2.kiwisdr.com, the cumulative delay sometimes reaches up to 5 seconds. I have therefore set a timeout of 4 seconds before the connection is flagged as failed. This seems quite long to me compared to most non-proxy servers, where the connection takes about a second.
So now, in some cases, I manually redirect the connection to proxy2.kiwisdr.com, while it seems logical to me that a load balancer in combination with a proxy server should transparently redirect the connection without the client noticing.
Another thought I have is: if the load balancer cannot transparently redirect the connection, wouldn't it be better to have the kiwi server registration point directly to the effective redirected server, which could halve the connection time?
@XPloRR It seems for Kiwi redirected to the secondary proxy server that web caching is broken. So the web server on proxy2.kiwisdr.com never decides it's okay to tell the client to use its cached version of files. I don't know why this is. But this would definitely slow things down. I will look into this.
But again this is the pitfall of flagging the initial connection to the primary proxy server as failed based on time. Rather than correctly detecting the HTTP 307 error which is sent instantly on the socket before the HTTP 101 transition to becoming a web socket.
This is especially problematic because the first time a primary-proxied Kiwi is visited there won't be any cached files and the delay will be similar to the time of the broken secondary-proxied problem. So this issue may persist even after the caching bug is fixed.
Of course, I did the update on my KiwiSDR2 BEFORE I saw it would cause an issue with your app. Now I can't load my Kiwi with it due to the new proxy address... Oops.
Just feedback that I would benefit from a fix for this. ☺️
Comments
New version of QiwiQ released: 2.05.60
• New socket connection procedure (to support proxy load balancing)
• Fix proxy load balancing: if the connection for xxx.proxy.kiwisdr.com fails, retry using xxx.proxy2.kiwisdr.com
• Strip trailing blanks from registration code field
• Audio hiccup fix when scrolling server or memory popup
Download at: https://bit.ly/3I49LfD
Feedback/bugs welcome!
@jks Remarks about the new proxy load balancer for proxy.kiwisdr.com servers.
I have spent quite some time developing a new socket connection method to support the load balancer. What I have noticed is that the connection to proxy.kiwisdr.com significantly slows down by the load balancer. For servers that are redirected to proxy2.kiwisdr.com, the cumulative delay sometimes reaches up to 5 seconds. I have therefore set a timeout of 4 seconds before the connection is flagged as failed. This seems quite long to me compared to most non-proxy servers, where the connection takes about a second.
So now, in some cases, I manually redirect the connection to proxy2.kiwisdr.com, while it seems logical to me that a load balancer in combination with a proxy server should transparently redirect the connection without the client noticing.
Another thought I have is: if the load balancer cannot transparently redirect the connection, wouldn't it be better to have the kiwi server registration point directly to the effective redirected server, which could halve the connection time?
@XPloRR It seems for Kiwi redirected to the secondary proxy server that web caching is broken. So the web server on proxy2.kiwisdr.com never decides it's okay to tell the client to use its cached version of files. I don't know why this is. But this would definitely slow things down. I will look into this.
But again this is the pitfall of flagging the initial connection to the primary proxy server as failed based on time. Rather than correctly detecting the HTTP 307 error which is sent instantly on the socket before the HTTP 101 transition to becoming a web socket.
This is especially problematic because the first time a primary-proxied Kiwi is visited there won't be any cached files and the delay will be similar to the time of the broken secondary-proxied problem. So this issue may persist even after the caching bug is fixed.
Of course, I did the update on my KiwiSDR2 BEFORE I saw it would cause an issue with your app. Now I can't load my Kiwi with it due to the new proxy address... Oops.
Just feedback that I would benefit from a fix for this. ☺️
-Nate
N8BTR
Can you send me your kiwi server address url either here or pm me, so I can debug.