-
Notifications
You must be signed in to change notification settings - Fork 197
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ergo.chat/abbreviated-handshake #1420
Comments
Two objectives: 1. Reduce thundering-herd effects on server restart (a cost of 4 should be approximately 1 millisecond of CPU time per reconnecting client) 2. Speed up mobile reattach as much as possible (see also ergochat#1420)
Two objectives: 1. Reduce thundering-herd effects on server restart (a cost of 4 should be approximately 1 millisecond of CPU time per reconnecting client) 2. Speed up mobile reattach as much as possible (see also ergochat#1420)
Regarding the 005 and all, sometimes those do change for legitimate reasons. Could we send some hashed value that represents those, that client client can store, and if the hashed value they get from us differs from what they have stored the client knows they should run |
Note from koragg, clients use the endofmotd/nomotd numerics to basically see that they are connected. We'll need to either send one of those, or send our own bespoke custom verb so clients can realise they're connected. wrt ^, maybe the value of |
From some initial benchmarking, it seems to me that the cost of the handshake is dominated by establishing the TLS connection and then the back-and-forth of conventional CAP negotiation, not by the registration numerics. Here's the test I ran (contains a non-sensitive password): https://gist.github.com/slingamn/c84b95452153e208b5d78f240930d664
Caveat: all of this is on wires, it could be that on mobile it's more important to get the server's response under the MTU, or into fewer send calls. cc @progval |
These figures are best effort and may be slightly off, I didn't necessarily make this data 100% ms accurate and are subject to visually rounding them and not computing ms when the times are >1 second. This is more to get a feel of the difference, if we have a particular aspect that we want to look at in more detail I can get more specific and accurate data. OragonoConnecting to a very small Oragono instance. Small amount of channels with practically empty NAMES list. Completing a reconnect with znc-playback which contains no new messages from prior session. Generally results in receiving 72 messages with a total of 8577 bytes (just counting for the IRC messages, not their representation in TLS/TCP/IP). Client sends 15 messages coming in at 584 bytes. Capability Negotiation looks like the following, including a PLAIN SASL login.
ZNC + Freenode + znc-playbackZNC generally skips a back and forth with SASL because it uses a server password which the client is able to send without negotiating sasl, asking for plain, etc. This also includes a cap-notify update after cap end because ZNC will update client once it knows which network it is connected to, with some upstream server features. This includes the client sending a push notification identification for Palaver Push. ZNC test does contain a lot more data because it is more "real world" I have joined larger channels with large NAMES for this test. Across the full session, we received 201 messages with 54277 bytes. We sent 20 messages at 767 bytes. The handshake (prior to 001) looks something like the following:
|
I'd also point out that is for single server, 1 connection. In real world you may be connected a few networks at once which competes for networking resources. |
I kind of want to make a "RFC 4959 but for IRC" to cut out this one round-trip... |
The intent here is to speed up reattaches for mobile clients. Basically:
oragono.io/abbreviated-handshake
CAP END
, the server will send001
but none of the other conventional registration numerics; in particular 005 and the MOTD will be skippedJOIN
lines for all joined channels (as usual), but will not sendRPL_NAMREPLY
@kylef is going to take a look at the potential impact of this.
The text was updated successfully, but these errors were encountered: