WS Connection suddenly drops about tokio-tungstenite HOT 16 CLOSED

Things like Node.js usually do more than you program - that is, pings are sent without asking. While this may be convenient for beginners, this makes the program much less predictable, so we decided not to go this way. If the connection really drops (Tungstenite notices it's dropped), and Error is returned. It may happen that the connection is closed due to timeout on other side but you don't see it until you try to send something, this is normal in TCP with certain network settings.

from tokio-tungstenite.

You're using unwrap(). This is the opposite of error checking - just "crash on all errors".

from tokio-tungstenite.

@serzhiio well...

1. As @agalakhov has already noticed, you're using unwrap() when you write to the stdout, if some of the actions which you manage with unwrap() fail, you won't see any websocket error, because it will cause a panic.

2. You're using wait() when you send the first message, was it meant like that? Be careful when you use wait(), it may work not as expected and if you cannot guarantee that the blocking work associated with a future is completed by any other thread, which might be the case, then you'll end up having a buggy program which simply does not work (refer to the docs please). It's also not clear what's the purpose of ok() after the wait(), given that you ignore the result anyway.

3. It's also not clear to me what do you try to achieve with by executing map() and using println!() inside it for the result future. Your future does not return anything meaningful (()), so the println!() won't print anything you're interested in here.

4. You're using then() on your result future which simply suppresses all errors and returns Ok(()) in your case, so even if error happened, you would not see it, because you explicitly wrote that you want to ignore them.

I hope it helped. If you take into account all these points, you will get the expected behavior. I'm closing this issue as it's not related to this crate (it's more or less understanding of tokio). If you still have any questions, feel free to ask them on the gitter's channel, there you can get the answers quicker, but I would advice to read the official docs from tokio.rs (and I believe that most people from tokio's gitter will suggest you to read the docs first as well). It may take a little bit more time to understand the "mental model" of futures (maybe a couple days of reading through the docs), but it'll definitely pay off in a longer run if you plan to work with Rust and do any async-related things (as tokio and futures are the core parts of it in the modern Rust). If you don't need anything like that and you would rather go with threads and very simple thread-based servers for small tasks, feel free to also take a look at our core library tungstenite-rs, which exposes a simple and obvious blocking behavior "by default".

from tokio-tungstenite.

Probably you should also send something in a reply? This looks like a server timeout. Most servers time-out if you don't send some specific heartbeat messages or acknowledgements. Please refer to the server's documentation to find which one it expects. If nothing special, then probably just sending normal WebSocket ping would help. Usually sending a reply right after receiving a message is the proper technique.

from tokio-tungstenite.

The simplest way to achieve this is to create a Stream of just periodic events, combine it with select with the stream of your messages to be sent and then forward to the sink.

Another way is just sending a message like receive.and_then(send) which is likely to work if you're really receiving a continuous message stream.

from tokio-tungstenite.

Reconnects may work, but usually you'll need some higher-level fine-grained control of them. Blindly reconnecting after every single disconnect error is likely to result in an IP ban. loop in the main function is Ok. Other techniques include making a stream of nothing using futures::stream::repeat() and doing connect in its and_then(). But be sure to analyze the reason of disconnecting and do not reconnect if you're disconnected not due to an accidental network error. Especially, do not reconnect if you're disconnected right after connect, and it is also not a good idea to reconnect after the server forcibly disconnects you because of your mistake. In both cases a repeated reconnect is likely to result in a ban.

from tokio-tungstenite.

This is most likely caused by network timeout at OS level. It's like a watchdog that kills forgotten connections. To keep the connection from dropping, just do some activity on them, i.e. just send WebSocket pings or, better, transfer some useful data.

from tokio-tungstenite.

from tokio-tungstenite.

from tokio-tungstenite.

Things like Node.js usually do more than you program - that is, pings are sent without asking. While this may be convenient for beginners, this makes the program much less predictable, so we decided not to go this way. If the connection really drops (Tungstenite notices it's dropped), and Error is returned. It may happen that the connection is closed due to timeout on other side but you don't see it until you try to send something, this is normal in TCP with certain network settings.

Ive totally forgot that my socket connection is not just being in idle state the data comes in constantly.

from tokio-tungstenite.

@application-developer-DA @agalakhov My friends thank you very much for such a grat explanatioan and in fuct my intruduction to Rust and Tokio :)
P.S: Короче говоря, огромное спасибо товарищи :)

from tokio-tungstenite.

Is it about connection drop by OS?
Protocol("Connection reset without closing handshake")

from tokio-tungstenite.

It may be. This happens if the connection gets suddenly closed by the peer or interrupted by some other part of the network (OS driver, firewall, router etc.) Usual causes are: (1) a connection timeout, or (2) the server (or firewall, or antivirus) did not like your last message and just bailed you out. Or also (3): the server you're connecting to just crashed or even rebooted.

from tokio-tungstenite.

Server is definitely not crashed neither rebooted. Every time after 60sec of actively reciving data abruption occurs. I cant figure out whats going on... Could you help?

from tokio-tungstenite.

from tokio-tungstenite.

from tokio-tungstenite.