HostClient via crossbeam and replication shortwiring

[g4borg]

So, I have set up Crossbeam for HostClient solution, as I had issues with stutter, and assumed, it is the "having two UDP Sockets communicating in the same process" problem, which leads to bad side-effects (usually on an OS Level), at least I have read this by now several times.

And voila, problems were gone.

Now however, I noticed, that with the Crossbeam Plugin, there is no separate entity (replication) anymore for client and server, so always only server entities. While on the surface this seems fine, I start to notice that maybe this is actually not always a welcome optimization: if I'd want to solve e.g. some determinism by letting the server compute in the future, it cannot manipulate distinct Transforms anymore from the Client, and I would still need to simulate replication even in in-process communication (and maybe set arbitrary delays)

Can I achieve entity mapping with crossbeam, just as if it would be local UDPs?

Do I misunderstand something here, about HostClient with the standard UDP Setup, was there actually a shortcut behind the scenes anyway, and I just blamed the wrong phenomenon?

[cBournhonesque]

I think you might be conflating two different things.

• Crossbeam is just an IO layer (similar to UDP, WebTransport, etc.). In crossbeam's case, the data is sent in-memory. Everything that can be done with UDP can be done with Crossbeam. Crossbeam is just means to transfer bytes.
• HostClient simply means that one of the ClientOf entities on the server (which track the clients connected to the server) is also a local Client entity. That means that the app contains both a Client and Server entity. There is no need for a Crossbeam IO because the two entities are part of the same app. If that happens, the Server entity will have a marker component HostServer, and the Client entity will have a marker component HostClient.

[g4borg]

Okay, maybe we talked past each other a bit here, I actually defined my own NetworkSetup plugin with a NetworkState I simply named HostClient (mainly from the examples back then), and did not use any internal "HostClient" from lightyear.
But now I understand why there is a component like that showing up.
It simply is the enum value that adds both lightyear ServerPlugins and ClientPlugins into the app.

What I did was this, when starting the client, if it is HostClient it will do this code:

        // HostClient: use in-process crossbeam link instead of UDP/Netcode
        let (client_io, server_io) = CrossbeamIo::new_pair();

        // Spawn the server-side link endpoint and associate it with the in-process Server
        let server_link = commands
            .spawn((server_io, lightyear::prelude::server::LinkOf { server: server_entity }))
            .id();

        let entity = commands
            .spawn((
                Name::new("HostClient"),
                Client::default(),
                ReplicationReceiver::default(),
                client_io,
                lightyear::prelude::server::LinkOf { server: server_entity },
            ))
            .id();

        info!(
            "Starting HostClient (crossbeam) client entity {:?} with client_id={}",
            entity, cfg.client_id
        );

        // Establish links for both endpoints and start the client
        commands.trigger_targets(LinkStart, server_link);
        commands.trigger_targets(LinkStart, entity);
        commands.trigger_targets(Connect, entity);
        Ok(())

while if it is not the client in the same process, I use this:

    let client_addr = SocketAddr::new(IpAddr::V4(Ipv4Addr::LOCALHOST), local_port);
    let entity = commands
        .spawn((
            Name::new("Client"),
            Client::default(),
            LocalAddr(client_addr),
            PeerAddr(server_addr),
            Link::new(None),
            ReplicationReceiver::default(),
            NetcodeClient::new(auth, NetcodeConfig::default())?,
            UdpIo::default(),
        ))
        .id();

    info!(
        "Starting client entity {:?} with client_id={} local_port={}",
        entity, client_id, local_port
    );

    commands.trigger_targets(Connect, entity);

The result is however, that on Crossbeam, I get no replication going, or at least, the entity for client and server are the same one, while if i used locally also the udp setup, I get duplicates.
Everything else, I do the same.

But if what you say is true, the mistake must be in how I do it, while I assumed, using the same entity is a side effect of using Crossbeams.

Do I understand it correctly, that maybe I need to add a NetcodeClient also to the Crossbeam setup?

[cBournhonesque]

I'm still a bit confused. From the code you're showing, it seems like you want to do the HostClient setup, where the Client and Server are running in the same app. You do not need crossbeam at all for this; since you don't need to send/receive messages.
You can see here how I create a HostClient (just by adding LinkOf and Client on the same entity).

In your case i think you can remove the server_link and the client_io.

[g4borg]

Still, thank you for trying to give help, tho.

Indeed, I have tried to follow back my refactorings, and try to find out, how I got to this weird code, by rewriting it in a more clean way, without e.g. the superfluous server_link and funky LinkStart triggers, which must have been desperate attempts to get something working, and I discovered what was the original issue back then after I upgraded from 0.16 to 0.23: Messages on the client did not arrive for the HostClient, the MessageReceivers never read anything.

This is why I actually added the crossbeam channel, which made Messages work with HostClient, or even used an UDP Client for a while on the Host+Client setup as well before (which also made replication create duplicates of entities, something I found really useful)

I was a bit lost in all of this, as the documentation fell behind the refactorings, and I could not follow your code since the split as much as before, so sorry for the questions.

I have seen that the code also contains a Separated solution (having Server and Client in separate threads), which I probably have to use if I don't get it working with the HostClient basically manipulating server entities, which might be fine with one player controlled object, but not when I try to have multiple.

[g4borg]

I have now found out the way to achieve what I wanted, by looking at your example in the test stepper, where I started to understand that I had indeed as you said mixed the concepts of HostClient and a local Client connection via crossbeams.

By creating the Server Link independently, that holds the server side of the crossbeams channel, and having the LinkOf to the server enttiy and the Client itself with a crossbeams client channel and the NetcodeClient, but without the LinkOf (which turned it into a HostClient), I could achieve a local connection in the same world, but still act on replicated entities, instead of directly modifying the ones from the server as HostClient does.

I hope I got this correctly now. I still have issues popping up with EntityMappers this way, but it seems to work now.

[cBournhonesque]

Awesome