Hi,
I am looking for a way to make users connect to the IRC server with everything loaded from the very first second.
Currently, there is a small delay that happens like this:
1. The user opens the chat page (preferably from a web browser).
2. They wait for "Looking up your hostname - Found your hostname (cached)".
3. The MOTD is loaded (but it is very short).
4. The RAW messages between 001 and 005 are received.
5. The user joins the channels (there is still a delay even with only 3 or 4 channels) and the nicknames are loaded.
After that, the user is fully connected. The whole process takes around 5 to 10 seconds. I am looking for a way to make the user fully connected within 1 or 2 seconds maximum.
Is there any way to achieve this?
This is mainly for UX/UI purposes.
UX/UI : Is it possible to make the user log in immediately without having to wait a few seconds?
Moderator: Supporters
Re: UX/UI : Is it possible to make the user log in immediately without having to wait a few seconds?
I really doubt you can speed up things much more, since most of that delay is just how IRC protocol works.
Joining channels adds its own delay time due to NAMES, the client has to do the handshake with the server, etc. All of that takes time.
The only thing that comes to my mind, that may slightly help, is removing the connect-info option from the set block.
Joining channels adds its own delay time due to NAMES, the client has to do the handshake with the server, etc. All of that takes time.
The only thing that comes to my mind, that may slightly help, is removing the connect-info option from the set block.
Re: UX/UI : Is it possible to make the user log in immediately without having to wait a few seconds?
@PeGaSuS
I just removed the "connect-info". It gives a better overall impression, so I'm going to leave it like this.
I just removed the "connect-info". It gives a better overall impression, so I'm going to leave it like this.
Re: UX/UI : Is it possible to make the user log in immediately without having to wait a few seconds?
Maybe I am mixing you with another French network, but last time someone was talking about big connect times it turned out their client was sending something like this:
CAP REQ :xxx
CAP REQ :yyy
CAP REQ :zzz
and so on.. for like 10-15 caps.. so lots of lines (and you actually get quite some lines "for free" in handshake, but they were over this)
Then once connected they were sending:
JOIN #a
JOIN #b
JOIN #c
JOIN #d
Again multiple lines, one for each channel.
All of this can be done more efficient:
1) you can CAP REQ in one go. If you saw the capabilities in CAP LS 302 then you can just CAP REQ them all (if it fits in one line, otherwise just use two lines or something):
CAP REQ :xxx yyy zzz etc etc
2) And for join you can join all in one go:
JOIN #a,#b,#c,#d
Just changing the joins from 10 times JOIN #chan to a single JOIN #a,#b,#c,#d, etc.. that saves you up to 10 seconds of fake lag.
And yeah maybe your client sends WHO #chan after that, for each channel, which will cause lots of data. But... not much can be done about that
But by then you already have joined the channel and have a nick list so that may be less of an issue? Your user should already be able to see the nick list, channel info, and be able to read and type... while the rest of the data (via WHO) is loading in the background.
If in doubt, look at the raw output of what your client sends and receives, similar to mIRC /debug -pt @debug and realize that every 1 line you send can cause up to 1 second of fake lag (artificial lag, security measure, not CPU or something).
Hope it helps
CAP REQ :xxx
CAP REQ :yyy
CAP REQ :zzz
and so on.. for like 10-15 caps.. so lots of lines (and you actually get quite some lines "for free" in handshake, but they were over this)
Then once connected they were sending:
JOIN #a
JOIN #b
JOIN #c
JOIN #d
Again multiple lines, one for each channel.
All of this can be done more efficient:
1) you can CAP REQ in one go. If you saw the capabilities in CAP LS 302 then you can just CAP REQ them all (if it fits in one line, otherwise just use two lines or something):
CAP REQ :xxx yyy zzz etc etc
2) And for join you can join all in one go:
JOIN #a,#b,#c,#d
Just changing the joins from 10 times JOIN #chan to a single JOIN #a,#b,#c,#d, etc.. that saves you up to 10 seconds of fake lag.
And yeah maybe your client sends WHO #chan after that, for each channel, which will cause lots of data. But... not much can be done about that
But by then you already have joined the channel and have a nick list so that may be less of an issue? Your user should already be able to see the nick list, channel info, and be able to read and type... while the rest of the data (via WHO) is loading in the background.
If in doubt, look at the raw output of what your client sends and receives, similar to mIRC /debug -pt @debug and realize that every 1 line you send can cause up to 1 second of fake lag (artificial lag, security measure, not CPU or something).
Hope it helps
Re: UX/UI : Is it possible to make the user log in immediately without having to wait a few seconds?
I just checked the "CAP REQ", and everything seems to be on one line.
As for "join", that could be the issue. I'll take a look.
As for "join", that could be the issue. I'll take a look.