ConcurrentHashMap上的Netty ChannelGroup

Question

I'm working on a multiplayer game server based on netty. Most of the messages transmitted to the clients are specific to a single client but sometimes i need to broadcast the same messages to all clients.

I'm not sure if there's a good reason to user a ChannelGroup over my own Map. So right now i have:

public class GameSession {
  /* a map of all the players part of this game session */
  private ConcurrentHashMap<String, PlayerHandler> players = new ConcurrentHashMap<String, PlayerHandler>();
  private final ChannelGroup playersChannels = new DefaultChannelGroup(GlobalEventExecutor.INSTANCE);

Where PlayerHandler is:

public class PlayerHandler extends SimpleChannelInboundHandler<IncomingMessage>

And contains stateful member variables.

When a new player joins (after going through some logic) he's being added to the GameSession:

public void addPlayer(PlayerHandler p) {

    if (p.getGameSessionID().equals(this.gameId)) {
        players.put(p.getPlayerID(), p); //add this player to our game session
        playersChannels.add(p.getChannelFromCtx()); //get channel and add to ChannelGroup
    }
}

Let's say i want to broadcast a message since a player requested to leave (or closed connection)

public void notifyPlayerLeft(String exPlayer) {
    //Broadcast message with the id of the player that left
    for (Map.Entry<String, PlayerHandler> entry : players.entrySet()) {
        PlayerHandler player = entry.getValue();
        player.sendPlayerLeft(exPlayer);

    }
}

Where sendPlayerLeft() is a simple method that does something like:

ctx.writeAndFlush(outgoingMsg)

If I use a ChannelGroup I can do something like this:

playersChannels.writeAndFlush(outgoingMsg, matcher)

but I'm not sure why that's a better idea. Netty states that it happens asynchronously but since PlayerHandler does not have its own thread, wouldn't iterating over the objects like I did in NotifyPlayerLeft() will also be async? Please note that this entire scenario will be triggered by one Channel/User/Thread.

I hope that my questions are clear enough. Thanks!

Answer 1

As you see here , Netty's default writing to a group is again a simple iteration. In that sense, there should not be a difference in performance and concurrency with your approach. The main difference is that it collects all futures into a Map, this grouping may help you track any problems raised. But why use your code if this is already implemented?

Answer 2

Updating it with information. So while the ChannelGroup is useful for the simple iterations as stated previously you also have this benefit taken from the API documents.

Netty.io 4.1 ChannelGroup API Documents

A closed Channel is automatically removed from the collection, so that you don't need to worry about the life cycle of the added Channel. A Channel can belong to more than one ChannelGroup.

You could go as far as creating a new ChannelGroup.class by extending the DefaultChannelGroup.class and add some methods to add additional behavior during the channel deregister to notify some code that a Channel is unregistered to then notify the other players, or do clean up.

Answer 3

Just be careful with Netty's ConcurrentHashMap; it is actually buggy; it is not threadsafe. You can verify this bug with concurrent stream on one thread while putting on another thread. It is not always failing since it has to do with non-atomic internal array mutations (fast pace concurrent r/w should fail with netty's but not jdk's.)