Can autoreconnect be used with a client connection?

[clarkewd]

On Windows 10, I can run this command with no problems:

websocat_win32.exe ws://echo.websocket.org

Is it possible to use the autoreconnect option as well? I haven't been able to figure out the syntax for this. I've tried these without any luck:

websocat_win32.exe ws://echo.websocket.org:autoreconnect
websocat_win32.exe ws://echo.websocket.org :autoreconnect
websocat_win32.exe autoreconnect://echo.websocket.org autoreconnect:

Thank you for creating and sharing wonderful utility.

[vi]

The syntax is autoreconnect:ws://echo.websocket.org

Note that in current version of websocat there is no delay or ratelimit of reconnect attempts, which may lead to flood / CPU busy spin.

---

What do you want to attain? Maybe there is another way to do it? Do you use websocat interactively or as part of some script?

[clarkewd]

Thank you for the fast reply!

I've downloaded the precompiled binary and on Windows 10 here is what I get:

c:\> websocat_win32.exe autoreconnect:ws://echo.websocket.org
Specify ws:// or wss:// URI to connect to a websocket
websocat: Invalid command-line parameters

I'd like to use it to send updates to another program, I'd just like it to recovery automatically if there were a wifi disconnect / reconnect. I'm open to any suggestions on that.

[vi]

Try websocat -t - autoreconnect:ws://echo.websocket.org.

autoreconnect: and other overlays are for non-simplified two-argument version invocation of Websocat.

[clarkewd]

worked perfectly - thank you!

[clarkewd]

Hi Vitaly,

I haven't used rust previously and I'm sure there are probably other things to consider, but would it be difficult to add a delay to the reconnect loop?

Would this work?

thread::sleep(::std::time::Duration::from_millis(500));

If it were added here?:

websocat/src/reconnect_peer.rs

Lines 99 to 102 in c14a1d3

	if !aux.already_warned {
	aux.already_warned = true;
	error!("Reconnecting failed. Trying again in tight endless loop.");
	}

Even a short delay seems like it would prevent the flood / CPU busy spin.

[vi]

I considered adding a delay almost from the very beginning, but at that moment Websocat contained no timers whatsoever, so I postponed it.

thread::sleep

Bad idea, as Websocat is single-threaded and polling and stopping entire thread should be avoided.

[vi]

Implemented proper timeout, also created a set of pre-compiled executables.

[clarkewd]

This is so great! Do you accept donations?

[Electrofenster]

Is there any update of the syntax?

➜  /tmp websocat autoreconnect:ws://echo.websocket.org
Specify ws:// or wss:// URI to connect to a websocket
websocat: Invalid command-line parameters

[vi]

No update on syntax. But samples above weren't right in the first place.
You need to use longer, two-argument form of Websocat invocation in order to use advanced features:

websocat -t - autoreconnect:ws://echo.websocket.org

Currently one-positional-argument form of Websocal command line is reserved only for trivial clients and servers without any overlays. The error message may indeed be improved.

You may also want to adjust --autoreconnect-delay-millis.

[uuonda]

@vi Can websocat handle intermittent disconnects without breaking overlayed TCP connections when websocket is used as a proxy? I've checked reuse-raw but it says it's "unreliable".

[vi]

I've checked reuse-raw but it says it's "unreliable".

"Unreliable" probably means that with multiple simultaneous clients reuse-raw would send data to some single, undetermined one. Also when TCP client abruptly disconnects, some (maybe unpredictable amount) data designated for it can be lost and not be seen by the next client (i.e. there are no acknowledgements and resends).

On the other hand, unlike reuse-broadcast:, it should not deliberately drop data to slow or missing clients - backpressure will apply.

With --conncap 1 one of the issues may be irrelevant.

---

... intermittent disconnects without breaking overlayed TCP connections ...

Do you need a reuser in the first place for this? Maybe just plain autoreconnect: would suit? I don't remember whether it would resend a message that triggered the reconnection (i.e. made Websocat realise that the WebSocket is not longer connected).

[uuonda]

@vi autoreconnect: corrupts SSH connection after websocket reconnects. Every other option I tried made SSH client aware of disconnect.

[vi]

Some data loss (hence encrypted connection corruption) is hard to avoid in this scheme. Holding a persistent and reliable connection over abruptly terminating and reconnecting WebSocket connections requires some overarching, persistent sequence numbers and retransmits (i.e. additional parts both at client and server).

Maybe you can set up Wireguard VPN over websocat (and then use SSH over that Wireguard connection)? Wireguard handles unreliable connections nicely and will provide slower, but more reliable link to users. If needed, Wireguard protocol can be used completely in userspace (using e.g. wgslirpy or onetun).

[uuonda]

@vi Would Wireguard actually help with this? I'm assuming my issue is not just mild packet loss along the way but some reverse proxy that abruptly closes websocket TCP connection.

I'm really cautious about adding more layers since that would be, like what, TCP (SSH) in UDP (WG) over TCP (WS)?

[vi]

abruptly closes websocket TCP connection

Dropped unacknowledged data when this happens would be interpreted as a packet loss by upper TCP layer.

... cautious ...TCP (SSH) in UDP (WG) over TCP (WS)?

Yes, it is TCP over TCP, which is problematic. The same layer that helps recover the data on reconnections would also cause slowdowns and overhead.

---

Maybe this specific task (good reliable stream socket over series of unreliable stream sockets) needs to be solved separately, with a dedicated tool. Maybe I'll roll such tool someday.