Websocket best practice for groups chat / one websocket for all groups or one websocket per group?

Question

I have to implement a chat application using websocket, users will chat via groups, there can be thousands of groups and a user can be in multiple groups. I'm thinking about 2 solutions:

[1] for each group chat, I create a websocket endpoint (using camel-atmosphere-websocket), users in the same group can subscribe to the group endpoint and send/receive message over that endpoint. it means there can be thousands of websocket endpoints. Client side (let's say iPhone) has to subscribes to multiple wbesocket endpoints. is this a good practice?

[2] I just create one websocket endpoint for all groups. Client side just subscribes to this endpoint and I manage the messages distribution myself on server: get group members, pick the websocket of each member from list of connected websockets then write the message to each member via websocket.

Which solution is better in term of performance and easy to implement on both client and server?

Thanks.

---

EDIT 2015-10-06

I chose the second approach and did a test with jetty websocket client, I use camel atmosphere websocket on server side. On client side, I create websocket connections to server in threads. There was a problem with jetty that I can just create around 160 websocket connections (it means around 160 threads). The result is that I almost see no difference when the number of clients increases from 1 to 160.

Yes, 160 is not a big number, but I think I will do more test when I actually see the performance problem, for now, I'm ok with second approach.

If you are interested in the test code, here it is: http://www.eclipse.org/jetty/documentation/current/jetty-websocket-client-api.html#d0e22545

Stouthearted

Answer 1

I think second approach will be better to use for performance. I am using the same for my application, but it is still in testing phase so can't comment about the real time performance. Now its running for 10-15 groups and working fine. In my app, there is similar condition like you in which user can chat based on group. I am handling the the group creation on server side using node.js. Here is the code to create group, but it is for my app specific condition. Just pasting here for the reference. Getting homeState and userId from front-end. Creating group based on the homeState. This code is only for example, it won't work for you. To improve performance you can use clustering.

this.ConnectionObject = function(homeState, userId, ws) {
            this.homeState = homeState;
            this.userId = userId;
            this.wsConnection = ws;
        },

        this.createConnectionEntry = function(homeState, userId,
                ws) {

            var connObject = new ws.thisRefer.ConnectionObject(homeState, userId,
                    ws);
            var connectionEntryList = null;
            if (ws.thisRefer.connectionMap[homeState] != undefined) {
                connectionEntryList = ws.thisRefer.connectionMap[homeState];
            } else {
                connectionEntryList = new Array();
            }
            connectionEntryList.push(connObject);

            console.log(connectionEntryList.length);

            ws.thisRefer.connectionMap[homeState] = connectionEntryList;
            ws.thisRefer.connecteduserIdMap[userId]  = "";

        }

Floris

Thanks, I will give the second approach a try, I will accept this answer when I have my load test result. – Stouthearted

Answer 2

Browsers implement a restriction on the numbers of websocket that can be opened by the same tab. You can't rely on being able to create as many connection as possible. Go for solution #2

Donaugh

Do you have any source for that? More than three years ago, the OP already wrote that he wants to take the second approach – Crossfertilize

@NicoHaase Many resources online point to these restrictions. I am also adding this as an answer because the original reason for the choice of #2 was based on perf analysis, which other people looking for this might not see relevent in their case and miss this obvious restriction #26004256 #22867052 – Donaugh