Wayk Client Entry - Connect/Disconnect/Reconnect Logic

Hi,

Automatic reconnection like RDP is not a supported feature at this point, but we will take note of it. It is unfortunately not a simple thing to implement correctly to handle all edge cases.

As for the connection behaviour, I'll get someone to look into it. Do you mean that every time you launch a session, it blocks all of RDM, while you can launch several RDP connections at the same time without blocking?

As for the "The session was disconnected by remote system" message, as far as I know, mstsc does behave in a similar way. If the disconnection reason is not show, wouldn't that be a problem if you wish to know why the session was disconnected? I know that if you initiated the shutdown yourself, you expect it, but we'd need a good way to know when you'd rather see the disconnect reason, and when you'd prefer not to see it.

Best regards,

Automatic reconnection like RDP is not a supported feature at this point, but we will take note of it. It is unfortunately not a simple thing to implement correctly to handle all edge cases.

I am aware. Thanks. But please, hardly an edge-case. I am sure many Wayk-users would look forward to an automatic reconnect ;-)

As for the connection behaviour, I'll get someone to look into it. Do you mean that every time you launch a session, it blocks all of RDM, while you can launch several RDP connections at the same time without blocking?

Correct. If I launch a Wayk Client session type connection, it blocks whole RDM, I can't click anything anywhere. About 10 seconds connection time per session, so quite a long time if I start many sessions. And quite annoying if I am in the middle of work, and others sessions are rebooting.

And btw. this is also a small annoying thing: why does Wayk need 10 seconds (!!) to connect. Comparable tools are way faster. Talking about 3sec vs 10sec in Wayk.

As for the "The session was disconnected by remote system" message, as far as I know, mstsc does behave in a similar way. If the disconnection reason is not show, wouldn't that be a problem if you wish to know why the session was disconnected? I know that if you initiated the shutdown yourself, you expect it, but we'd need a good way to know when you'd rather see the disconnect reason, and when you'd prefer not to see it.

Well, we are not talking mstsc here, but rather RDM. I know mstsc shows that annoying message, it's why I am not using it, and paying you guys for RDM ;-). Anyway, I have RDM handle sessions like this: my tabs remain open, and I see SRV01 - Disconnected. This is enough for me to see which machine is offline or then reconnect it. I don't need popups or whatever. And what I like even more, is that I can choose with RDP if I want to close, connect or connect when available. But I was told that currently this cannot be implemented... but maybe you could implement the "SRV01 - Disconnected" in the tab, like RDP does.

Hi,

We have created a ticket to make the Wayk connection non-blocking and remove the current modal dialog, which should allow the launching of sessions in parallel without having to wait for the previous one to complete.

As for the disconnect message, we'll create another ticket to see how this behavior could be adapted to avoid showing the disconnection reason, and simply change the embedded tab title instead to show "Disconnected" or something like that. The idea is that you just don't want a message box. What about connection failures, like when you don't have sufficient permissions to connect, or the target machine could not be reached? This is probably the time where you really want to see that error message with a description. I guess we could always adapt the "post-connection" behavior differently from all errors that occur before the connection is initially completed with success.

Best regards,

Hi,

We have created a ticket to make the Wayk connection non-blocking and remove the current modal dialog, which should allow the launching of sessions in parallel without having to wait for the previous one to complete.

Many thanks, sounds good.

As for the disconnect message, we'll create another ticket to see how this behavior could be adapted to avoid showing the disconnection reason, and simply change the embedded tab title instead to show "Disconnected" or something like that. The idea is that you just don't want a message box. What about connection failures, like when you don't have sufficient permissions to connect, or the target machine could not be reached? This is probably the time where you really want to see that error message with a description. I guess we could always adapt the "post-connection" behavior differently from all errors that occur before the connection is initially completed with success.

This is indeed correct: I definitely want to see messages when I can't connect, an error, permission... or simply unplanned disconnect. A message box requires me to click around and is work-disruptive, and "-Disconnected" is simply informational. It's the same with RDP. If the connection is lost, I will start getting errors, but if the computer restarts, or I cause it, it will simply say disconnected. But I still need to be on the console, I need Wayk maintain the physical connection.

The only reason why I am looking to move away from Teamviewer is a solution that will enable me to do maintenance on multiple customers computers. But I cannot compromise. Currently, TV does "OK" in 1:1 sessions, but multiple sessions... big meh. The tool must allow me to work much more efficient.

Hi,

I have compared with how we're doing it for RDP, and opened a ticket to improve the behavior when "keep tab on disconnect" is enabled.



Best regards,

Indeed that's correct, that is the setting I am using. And ultimately, as I suggested somewhere else, RDP has an option "connect when available". I don't see why this couldn't be implemented at this stage too. Wayk state can be detected, so when it comes online, this should work...
(currently, the offline/online detection doesn't work here, but there is an open ticket about this too, most likely firewall problem)

Indeed that's correct, that is the setting I am using. And ultimately, as I suggested somewhere else, RDP has an option "connect when available". I don't see why this couldn't be implemented at this stage too. Wayk state can be detected, so when it comes online, this should work...

We'll consider that too, after we've made a first batch of improvements for the other things you have already requested.

(currently, the offline/online detection doesn't work here, but there is an open ticket about this too, most likely firewall problem)

We've tested it on our side, and it does detect the disconnection the moment Wayk Bastion loses the WebSocket connection with Wayk Bastion. We are 99.99% certain this is an issue caused by the reverse proxy you are using, as we have seen issues in the past where reverse proxies would keep WebSocket connections open based on a configurable "tunnel timeout" even if one side closed the connection. Because of this type of interference by the reverse proxy, the Wayk Agent correctly disconnects, yet Wayk Bastion thinks the connection is still there - because it is artificially kept alive by the reverse proxy. This is why it takes a while to detect the disconnection, the workaround for us is to ping at regular intervals to detect "zombie" WebSocket connections that are still connected, yet won't respond to ping/pong requests.

We have created a ticket to make the Wayk connection non-blocking and remove the current modal dialog, which should allow the launching of sessions in parallel without having to wait for the previous one to complete.

Is there any update on this issue?

We have created a ticket to make the Wayk connection non-blocking and remove the current modal dialog, which should allow the launching of sessions in parallel without having to wait for the previous one to complete.

Is there any update on this issue?

Hi, it is still a work in progress. I will soon be at 100% on this task.

Thank you for the update.