Server-side Networking: Client sockets stored in a resource or as components?

[ItsDoot]

When it comes to server-side architecture, what practical (or theoretical) considerations should be made about where client socket connections should be stored?

The way I see it, we have simply two options:

pub struct PlayerConnection {
    reader: SomeSocketReader,
    writer: SomeSocketWriter,
}

// As a Resource:
pub struct PlayerConnections {
    connections: HashMap<Entity, PlayerConnection>, /* or some other ID component stored on the player instead of Entity */
}

// Or as a Component:
#[derive(Bundle)]
pub struct PlayerBundle {
    connection: PlayerConnection,
    // ...
}

I've seen a few discussions about this problem in the Discord, but wanted to centralize information.

Specifically, I'm looking to discuss the benefits and drawbacks of each approach.

[elaforma]

If you're using Entities as the key on your HashMap, then there will not be any benefits vs using components, since you basically implement the same logic manually. It might actually have downsides, because you cannot use Bevy queries to load the component and have to do it manually.

However, you might not always have a clean 1:1 mapping between Entities and players. There might be multiple Entities spawned that are controlled by a player. In that case, having a PlayerID as a component and looking it up through a global HashMap might actually make more sense. However, that would add an extra layer of indirection, which may have performance implications.

IMHO, storing the connection as a component is more idiomatic for an ECS like Bevy.

[minecrawler]

I think it depends on the game. Sometimes, a reactive pattern might make sense (e.g. online, but not multiplayer), sometimes slapping the connection as Component onto the Entity is the way to go (e.g. MMOPRG). Other times, storing the Connections on a struct as a Resource is just what you need (4vs4 chess? idk.). I don't think there is "the one correct way" to store connections...