How to read TCP stream using ractor?

[EnvOut]

Hello guys
For TCP stream reading actix has add_stream

        let (mut socket, _) = listener.accept().await?;

        // tokio::spawn(async move {
        let (r, mut w) = socket.into_split();
        let client_address = r.peer_addr()?;
        let mut connection_ref = TcpConnectionActor::create(|ctx| {
            let parts = actix_codec::FramedParts::new(r, BytesCodec);
            let framed = Framed::from_parts(parts);

            let actor = TcpConnectionActor::new(w, connections.clone(),client_address, acive_aconnections_actor.clone());

            ctx.add_stream(framed);
            actor
        });

What about ractor? How I can read/write TCP stream using Ractor?

[slawlor]

We have a pretty similar example in ractor cluster which is hosting a TCP server socket then reading and writing through various streams. Each TCP connection instantiates an actor which has two children, one for for writing and for reading to the stream concurrently. Messages are sent to the TCP connection actor which yet serialized and sent over the stream.

Those portions of it aren't too specific so I think they should be a pretty good example of how to deal with sockets, although they are utilizing protobuff for binary encoding

[EnvOut]

When I listen TCP stream, should I run actor-handle inside of tokio::spawn:

        let listener = TcpListener::bind(addr).await?;
        let (con_store_ref, _) = Actor::spawn(None, ConnectionStoreActor::new(), ()).await?;
        
        loop {
            let (socket, _) = listener.accept().await?;
            tokio::spawn(async move {
                let (_, handle) = Actor::spawn(None, ConnectionActor, (socket, con_store_ref.clone())).await?;
                let res = handle.await;

                if let Err(err) = result {
                    log::error!("err: {:?}", err);
                    println!("err: {:?}", err);
                }
            });
        }
    }

Or for production app we can remove tokio::spawn and not await actor handle?

       let listener = TcpListener::bind(addr).await?;
       let (con_store_ref, _) = Actor::spawn(None, ConnectionStoreActor::new(), ()).await?;
       
       loop {
           let (socket, _) = listener.accept().await?;
               Actor::spawn(None, ConnectionActor, (socket, con_store_ref.clone())).await;
       }
   }

[slawlor]

If you're already in an async context, you shouldn't need to spawn with Tokio just to spawn an actor.

Additionally, binding to the port is a generally fallible process, so putting it into the actor's pre-start is usually how you'd want to handle it so that things like panics and stuff are caught for you

[tylerhjones]

@slawlor Is this the desired pattern for handling incoming requests for ractor? Im thinking about thefaq section of the site talking about not spawning short lived actors. In the above example it does just that correct? (im pretty new to rust and actors so bear with me). Is there a more efficient way to do this with ractor to not continually spawn actors or is that required in this case to be practical?

Is there a guide/example for answering http with ractor? It seems possible to have a single actor that accepts ownership of sockets via a message and have it dispatch messages to fulfill the response, but maybe im overthinking/imaginative on what is the most practical solution.

[slawlor]

Yes in this context a connection is a long lived actor. A short-lived actor in this world would be like an actor for every packet, that would be an anti-pattern.

But even if the connections are short, if they handle multiple packets, for example like a handshake, that can still be very worthwhile to encapsulate in an actor.