UnrealIRCd Forums

Hello,

For about a week now, users on my chat have been able to connect using the same IRC account (same nickname) with up to three simultaneous sessions, for example on a computer, on a mobile device, and another one in case of a ping timeout bug or similar issue.

However, I am facing a problem: the connection process is very slow because users rejoin channels they have already joined before, which is unnecessary. Removing this behavior from my system would take too much time, so I am considering implementing a solution using fake lag, or increasing the flood limits and block class settings.

Here is my client class:

class clients
{
pingfreq 180;
maxclients 1000;
sendq 300k;
recvq 8000;
};

What values would you recommend for sendq and recvq?

Here is the profile of my IRC server.

The server is hosted on a dedicated machine with 32 GB of RAM and up to 600 users connected simultaneously at peak times.

At connection time, the IRC server applies security checks. It primarily allows users coming from the web-based applet in the browser. These users have an ident starting with "o-*", and this prefix is protected by a module called Authpass, which requires sending a SHA-256 password based on the nickname and the server password.

IRC clients such as mIRC, AdiIRC, and similar are very rare. There are around five users per day using such clients.

As for cloners or spammers, they cannot do anything from mIRC, AdiIRC, or any non-web applet. The port 6667 is disabled, and they cannot join any channel because all channels are set to +I (capital i), with extended ban exceptions that allow idents starting with "o-*" and registered users, but no one else.

In short, any significant flooding can only come from users connected through the web applet, or from the few mIRC users. What configuration would you recommend for blo

users on my chat have been able to connect using the same IRC account (same nickname) with up to three simultaneous sessions,

This doesn't sound like UnrealIRCd at all. As far as I was aware, I had the only custom module for multi-session IRC connections, and I hadn't told anyone about it either, and it's very recent also...

As for reducing join flood, if a second user is joining the session of an existing user and that user is already in channels, the IRC client still needs to get the state of the user, including all the channels, otherwise there will be a state desync and lots of things will break. You said it's taking a long time for them to connect, are you spawning multiple sessions at once? If the first session is in multiple channels, especially with lots of history, it will likely take significantly longer to join them and process the chat history than it would without all that statefulness and even without trying to join multiple sessions at once, so I would guess that this is expected.

I think it's more likely that this is not an UnrealIRCd custom module or feature, because it only makes sense to rate-limit multiple JOIN requests. If it were an UnrealIRCd module, there wouldn't need to be JOIN requests (unless it were doing something annoying like which doesn't make sense because it would fly in the face of internal statefulness in a multi-session situation) because the user would already be in the channels and the server would just need to share that information without any fakelag, and not by the client sending a JOIN request.

Please could you clarify what you meant?
Perhaps you are seeing the JOIN events in a session where the user was already connected, as well as in the new session? Indeed that would be a bug, but not something any of us on this forum are going to be able to help with. If you bought the module off someone then you should be contacting that person directly.

Or perhaps you meant something entirely different? Perhaps you have some middleware which provides this multi-session stuff? Maybe a bouncer of some kind?

Either way, please provide more information and context.

@Valware Here is the technique I use, only for IRC via a web browser:

1) I have had a web client for several years now. It is very frequently revamped and improved, and today it has become something pretty impressive. Let’s say it is the little brother of KiwiIRC, since its base was created (and purchased) from a KiwiIRC developer back in 2017. Since then, I have been improving it very often (almost every month). The applet server uses IRC-Framework.

2) Between July 2020 and Saturday, December 20, 2025, clients authenticated via SASL were automatically connected through a BNC. The session ended after 1 hour and 30 minutes of inactivity (real inactivity: the BNC no longer pings the applet).

3) I decided to improve the applet server starting December 20, 2025. I therefore disabled the BNC that I had been using since 2020. Now, my multi-user web client connects to the web client server (via socket.io), and this server then connects to IRC-Framework (using a new IRC.Client() from IRC-Framework) for each unique user account. It is a kind of persistent BNC.
Users who are already connected to IRC and want to reconnect do not use a new IRC.Client(); instead, the previous instance is reused. The entire server-side of the web applet handles the automatic disconnection after 1 hour and 30 minutes of inactivity, once socket.io no longer detects any connected clients on its own socket.
As before, users can still use /quit, but it is not automatic via the browser’s red close button. They must go to a specific tab labeled “Disconnect from BNC” to perform a real quit. About 70% of users do not do this and simply let the session expire.

4) Today, this system works very well and I am happy with it. I spent almost a full week coding it day and night, barely eating because I was too addicted to coding, and I even lost 3 kg in one week. However, when I connect to three sessions of the same user (with the same nick), it generates a heavy load with JOIN/WHO/userlist requests. It is slow, but at the same time this is for testing purposes: I refresh each page 3–6 times. Still, I feel it is quite slow and could probably be faster.

Thanks for providing a lot of information! From what you've told me, I think the slowness would be from the middleware you specified. This middleware should be in charge of properly tracking state for each user and forwarding them correctly to each user's session, instead of requesting the information freshly each time from the IRC server. If you do request this information freshly each time, that could definitely cause the slowness you described. I think this is what you meant when you said:

However, I am facing a problem: the connection process is very slow because users rejoin channels they have already joined before, which is unnecessary. Removing this behavior from my system would take too much time

This would likely be contributing to the significant bandwidth overhead, which will still affect your middleware as it would now need to send the reply to each JOIN request to all connected clients (which, you're kind of lucky that isn't desync already, because this is not the way to do it). To say another way, it sounds like the overhead is happening in the middleware still, due to the need to show all sessions duplicate information whenever a single new session joins, which is why it might appear slow on the user-end, so I don't believe changing the sendq or recvq for this would make any noticeable difference.

The best and most performant way to do this, in my opinion, is to implement proper state tracking in your middleware, cache it instead of requesting fresh info each time. This should speed things up significantly.

@Valware, Ah yes, I see how to handle that, but it would be complicated to put in place. So it would mean setting up a system to avoid sending join/part/quit commands if they have already done it, or something like that.

I’m pretty happy with the persistent BNC I built using IRC-Framework. It’s stable and much better than the BNC I was using before.
Here’s everything I’ve done:
1. An object-based system using new IRC.Client() for SASL users.
2. A system to resume the current session by reusing the same object, so IRC.Client() is not called again.
3. A system to restore messages by saving up to the last 500 messages per session, whether users are online or not. When the client reconnects, it sends to socket.io the last message received on the web browser client, with a date like this: 2025-12-30T15:49:51.424Z. Messages are then restored after that date. I had to do it this way because mobile devices don’t close the socket properly; there are latency issues. I found a solution by saving all messages sent to the client via socket.io and restoring them based on the date of the last message received on the client. It’s fairly functional for now.
4. I rebuilt the old special vhost system using WEBIRC.

I have the impression that people are a bit more active now and less bothered than with the old system. For me, it also means one less BNC server to manage, which is great. I think 2026 will start like this, with the abandonment of the BNC server I’ve been using since 2020. I had never thought before that it was possible to use IRC Framework as a web BNC with the help of socket.io; you just need to avoid sending “/quit”.

For now, I’m really happy with it, no issues to report, and it’s so much simpler now.

Since my last message on December 30, I have improved this entire BNC web system using IRC-Framework, and it is now much more performant.

Here is how it works:
1. The user connects with their SASL account from the applet.
2. The server side (socket.io) of the applet starts an IRC-Framework session (a new IRC.Client()).
3. The client is never connected directly to IRC, because all messages are sent and received in an ordered way between socket.io and IRC-Framework.
4. When the user connects or reconnects to their Web BNC, they connect only to socket.io. Only the socket.io server and socket.io client are involved, and all messages are sent and received via IRC-Framework.
5. To make the bot (and especially the user) quit, the user must send /quit, which also closes the socket.io session and forgets that the user was connected.

As a result, it works very well. There is no need to use a traditional standalone BNC.

After that, it is just a matter of handling how messages are redistributed, with timestamps, as I mentioned in my previous message.

Regarding the flood issue with 2 or 3 clones connected at the same time, I see where the problem is. In fact, when one client executes an IRC command, the other two clients do the same, which explains the flood. It mainly happens on reconnection, when the clone joins.

Good to hear you have solved the problem and made a nice system