Redirect to the next kiwisdr.

loststationloststation
in Problems and Issues
Sometimes the redirect to the next kiwisdr does not work. Appears: "Sorry, the KiwiSDR server is too busy right now (4 users max)." Apparently this happens when the last free slot is trying to occupy 2 users at the same time.

Also, it would be nice at the time of the update to keep the ability to redirect to the next kiwi instead of the “update” message, if it's real.

Thank you.

Comments

  • jksjks
    edited October 2020
    Apparently this happens when the last free slot is trying to occupy 2 users at the same time.
    I'm not sure what you mean exactly. Do you mean when two users are trying to connect simultaneously to the last channel of the first Kiwi in a redirected chain? (e.g. channel #4 of a 4-channel Kiwi1 that re-directs to Kiwi2). The redirection code was tested pretty carefully. But of course that doesn't mean there isn't a bug someplace.

    Also, it would be nice at the time of the update to keep the ability to redirect to the next kiwi instead of the “update” message, if it's real.
    That's an interesting idea. Hadn't occurred to me before.
    WA2ZKDPowernumpty
  • loststationloststation
    Yes, you understand correctly. This is a longstanding problem. Alternatively (kludge), you can catch the output "Sorry, the KiwiSDR server is too busy right now (4 users max)", if it somehow miraculously happened, and force a redirect.
  • jksjks
    edited October 2020
    The second problem (redirect if update in progress) will be fixed in the next release.

    The first problem is very difficult to fix. It is a race condition. But more importantly the race window is very small. How often do you have two users simultaneously (within a fraction of a second of each other) trying to connect to the last open channel?

    The problem is that the redirection must occur in the web server when the connection to the Kiwi "index.html" page first occurs. That is the only time that an HTTP 307 redirect can be returned. But the Kiwi rx channel is not allocated at that time. It is allocated slightly later on when the HTTP connection has been upgraded by to a web socket connection. You can't simply redirect when the "sorry too busy" page is displayed because the connection is already a web socket by then.

    The only way to fix this would be to have the web server set some sort of flag at initial connection time that reserved the channel. But this is a very dangerous thing. You have to be extremely careful not to have channels get reserved that subsequently receive no corresponding web socket connection. And potentially hang becoming a useless channel that no one can ever connect to. That means careful timeouts and other checking. This sort of checking happens for other situations where the client connections just disappear in strange ways. We have seen this and applied fixes many times over the years.

    So I am very reluctant to try and develop a fix for a problem that shouldn't be occurring frequently at all. Especially a fix that would require a lot of careful testing to make sure it doesn't disturb any of the existing connection scenarios we have at present.
  • jksjks
    Okay, according to RFC6455 it is possible for web socket upgrades to return HTTP error codes (i.e. 3xx). But it isn't clear from a quick look at our web server code (Mongoose) if this is supported. Some experimentation would be required. Again, I don't think this problem occurs often enough to warrant that kind of effort.
  • loststationloststation
    This is a rare situation.
    Okay. If I have any thoughts on how to solve this, I will write to you.
Sign In or Register to comment.