Processing multiple requests per each user about tokio-tungstenite HOT 9 CLOSED

No. The event-based API is generally a bad idea since it has multiple issues with object lifetimes, order of calls etc. (see https://www.manning.com/books/functional-reactive-programming for example). The whole idea of Tokio is to get rid of these callbacks.
However, Tungstenite is flexible enough to be wrapped into a callback-based compatibility layer, if you really want to have a callback-based API.

The current API is much simpler than the on_something based one:

• You just connect the socket, so you don't need on_connect: you just do whatever you want directly after the call to connect().
• You just read from the socket, so you don't need on_message: a successful read gives you a message.
• Disconnect is handled like an error, you'll just get Error::ConnectionClosed and handle it.

from tokio-tungstenite.

• Yes. Every request can fail due to a network failure, the peer violating the protocol or something else. It's network, and errors are likely to happen. Not handling these errors is a common source of bugs. Thus we force the user of the library to write proper error handling for all important cases. You can just treat most errors as fatal resulting in simply dropping the connection, but many applications need more complex error handling.
• The connection won't be closed automatically by the Tungstenite library, but it may be already closed by the OS due to an I/O error. But the connection is automatically closed if dropped, so you don't have to do anything special about it in the error handler. Just forget about the connection, and it will be closed.
  It is a bit different with Tokio-Tungstenite. In Tokio, you usually pass your connection in the read function by value. In case of an error you just won't get your connection back which means it's closed. In the rare cases where the connection may be still needed it is returned back as a part of the error value.
• ConnectionClosed is returned if the connection is closed normally by the server (i.e. the server called close()). It is not something like an I/O failure. This is likely to be a legitimate close, and you're unlikely to want to reconnect in this case. It depends on the server however. Some servers may sporadically disconnect you for whatever reasons. This is out of scope of Tungstenite, of course.

from tokio-tungstenite.

The Tokio-based pseudocode of processing is

connect_async(websocket_url)
    .and_then(|conn| {
        // your on_connect code here
        Ok(conn)
    })
    .for_each(|msg| {
        // your on_message code here
    })
    .or_else(|err| {
        // your on_disconnect and on_error code here,
        // disconnect is just a special case of error
    })

As you can see, you don't really need on_something functions. In contrast to the traditional approach where the library calls your functions, here you're calling the library. This allows for much more flexibility. You may even combine multiple functions to do very complex processing, much more complex that is possible in the traditional approach. And it is easier.

from tokio-tungstenite.

Hi,

• Most likely there is everything you may need. A .for_each() method of WebSocket would call your processing function for each incoming request. If you want to process them in background, just spawn Tokio tasks for the processing. It's unlikely that you'll need an extra wrapper.

• Yes, you can. Just go on and check the credentials after the handshake is finished but before you enter the main processing loop. There is nothing special about it, as Tungstenite is NOT event-driven. The WebSocket is represented as a Stream of messages and does not use on_message() or similar event handlers, so just do any checking you need before you start to read messages from the stream.

from tokio-tungstenite.

Tungstenite is definitely not the place where such methods should be placed, tungstenite is a simple, lightweight but yet powerful library which allows you to build more complex wrappers around it. For instance, you can build a library which is equivalent to ws-rs but based on tungstenite (you can use ws-rs concepts to present an ws-rs-like API and use tungstenite as an internal core).

As for tokio-tungstenite, it does not require such methods (on_message etc), as it's future based, i.e. there are quite a few ways to write a code which will be executed when the message is received or connection is completed (some of them you can find in our examples section). Basically tokio-tungstenite is just a wrapper around tungstenite, which allows users to easily integrate tungstenite in their tokio stack without the need to wrap all tungstenite function calls and structures (but you can use tokio version even if you don't use tokio at the moment though, for instance from a separate thread, this would help you to hit the ground running).

from tokio-tungstenite.

Does the tungstenite/tokio-tungstenite library plans about providing clean and convenient APIs like method on_message / on_connect / on_disconnect like it provided as the autobahn-ws library?

from tokio-tungstenite.

Thanks you for the detailed answer!

from tokio-tungstenite.

Hm, it makes a sense... However, raised a few questions about error processing per each request separately:

• As far as I understand for each request I could returns any type of errors? (from original tangesnite crate)
• Unsuccessfully read message from a socket will return only an error? Or it also close an existing connection?
• If for one of those requests (from certain client) will return Error::ConnectionClosed, then it will be mean that necessary to re-establish a new one connection with the server, right? Or it happens only when I manually invoked the close() method?

from tokio-tungstenite.

Got it! Thank you.

from tokio-tungstenite.