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

Add `migrate` extension #330

Open
wants to merge 1 commit into
base: master
from

Conversation

Projects
None yet
4 participants
@aji

aji commented Nov 13, 2017

I'm working on an implementation over at https://github.com/aji/charybdis-migrate (No code yet. The code is all on my hard disk and is half-written, but my approach is outlined in the document.)

I think migrate addresses a big gap in the IRC client-server protocol.

migrate is designed to be dead simple for clients to implement, at the expense of more complex server-side implementations, especially for s2s protocols like TS6 that have no central authority to coordinate something like this. The idea is that if it's easy for a client to implement, then more clients will implement it and server authors won't feel like their effort is wasted by implementing it.

I want to hear people's thoughts so I don't waste my own time putting together a proof-of-concept in charybdis-migrate.

appropriate client cooperation.
Clients that support the migration protocol outlined in this document should
register the `migrate` client capability. If the server supports client

This comment has been minimized.

@DarthGandalf

DarthGandalf Nov 13, 2017

Member

It starts with server advertising it in CAP LS. The current text looks like it's tailored for clients which blindly request everything they support, without sending CAP LS

This comment has been minimized.

@aji

aji Nov 13, 2017

I can be more precise here.

protocol are described later in this section.
1. The server sends `MIGRATE START` to indicate that it wants to migrate the
client to a different server. Included in this message are a *resume token*

This comment has been minimized.

@DarthGandalf

DarthGandalf Nov 13, 2017

Member

and address of the new server

This comment has been minimized.

@aji

aji Nov 13, 2017

Ah, I hadn't intended for this line to list everything in the message. I'll add a bit at the end that mentions the other fields.

This comment has been minimized.

@ProgVal

ProgVal Nov 13, 2017

Contributor

and port

Other users in `#chan` will see messages 1 2 and 3 as if the client's connection
was left untouched.
## Client-initiated migrations

This comment has been minimized.

@DarthGandalf

DarthGandalf Nov 13, 2017

Member

The previous text should have a title Server-initiated migrations

This comment has been minimized.

@aji

aji Nov 13, 2017

Well, "client-initiated migrations" are basically clients requesting that the server begin a server-initiated migration, and they're intended to be issued manually. I'll rephrase the title of this section to something like "Manually requesting a migration", or possibly omit it entirely. (Server authors will add appropriate additional commands for users and operators to trigger migrations so I'm not sure there's much value in specifying those commands.)

s1 <- PRIVMSG #chan :message 2
s1 <- MIGRATE OK abc
s1 -> :s1 MIGRATE PROCEED abc
(client disconnects from s1, connects to s2:6697 using TLS)

This comment has been minimized.

@DarthGandalf

DarthGandalf Nov 13, 2017

Member

This doesn't allow client to connect to s2 first, and then disconnect from s1, which will result in some downtime. I don't know how important that is.

This comment has been minimized.

@aji

aji Nov 13, 2017

Hm, I'll have to think about the implications of that one. It should be fine but I want to give it some thought first.

1. `REQUEST`, indicating the `MIGRATE REQUEST` operation
2. The network-internal name of the server the client wishes to be migrated to.

This comment has been minimized.

@DarthGandalf

DarthGandalf Nov 13, 2017

Member

Where to find such name?

This comment has been minimized.

@aji

aji Nov 13, 2017

This is the name in /map, /links, /whois, etc. The spec tries to distinguish between those names and DNS names, because there's not always a 1-1 mapping.

1. `START`, identifying the command
2. The client-reachable address of the server that the client will eventually be
migrated to. This can be either a domain name or an IP address, but should be

This comment has been minimized.

@DarthGandalf

DarthGandalf Nov 13, 2017

Member

IP address in text format, I assume, not DCC format?

This comment has been minimized.

@aji

aji Nov 13, 2017

Yes, text format. I'll clarify.

2. The client confirms the migration request with `MIGRATE OK`. After sending
`MIGRATE OK` the client should stop sending normal IRC traffic, as it will
not be processed. If for some reason the client does not wish to migrate,
then the migration fails. After receiving `MIGRATE OK`, the server can begin

This comment has been minimized.

@ProgVal

ProgVal Nov 13, 2017

Contributor

Should it reply explicitely it does not want to migrate? (eg. MIGRATE NAK)

This comment has been minimized.

@RyanSquared

RyanSquared Nov 30, 2018

I'm not sure how it would "fail" otherwise, other than that it just wouldn't happen and the server would keep waiting on it.

client to a different server. Included in this message are a *resume token*
and *confirm token* that will be used when connecting to the new server.
2. The client confirms the migration request with `MIGRATE OK`. After sending

This comment has been minimized.

@ProgVal

ProgVal Nov 13, 2017

Contributor

What about MIGRATE ACK, to use the same vocabulary as the cap negotiation specs?

1. The server sends `MIGRATE START` to indicate that it wants to migrate the
client to a different server. Included in this message are a *resume token*
and *confirm token* that will be used when connecting to the new server.

This comment has been minimized.

@ProgVal

ProgVal Nov 13, 2017

Contributor

You should specify the format of the message with these two tokens. I think it is rather clear what you mean, but since you are writing a specification, it is better to be explicit.

the exact semantics of this message.
5. The new server sends `MIGRATE CONFIRM`, containing this migration's confirm
token. If the confirm token does not match, the migration fails.

This comment has been minimized.

@ProgVal

ProgVal Nov 13, 2017

Contributor

Could you state explicitely what "the migration fails" implies at this point?

reachable by the client.
3. The port that the client should use when connecting to the new server. An
ASCII plus character (`+`) before the port indicates that TLS should be used.

This comment has been minimized.

@ProgVal

ProgVal Nov 13, 2017

Contributor

What happens if the old server uses STS, but does not use a + here?

MIGRATE RESUME 5AEAD4D0
CAP LS
NICK aji
USER alex * * :Alex

This comment has been minimized.

@ProgVal

ProgVal Nov 13, 2017

Contributor

This contradicts what you wrote above:

  1. On connecting to the new server, instead of using the normal connection setup
    protocol (NICK, CAP, etc.) the client sends a MIGRATE RESUME message
4. On connecting to the new server, instead of using the normal connection setup
protocol (`NICK`, `CAP`, etc.) the client sends a `MIGRATE RESUME` message
containing this migration's resume token. Refer to later documentation for
the exact semantics of this message.

This comment has been minimized.

@ProgVal

ProgVal Nov 13, 2017

Contributor

Wouldn't it be required to do another capability negotiation, in case the new server does not support the same set of capabilities?

This comment has been minimized.

@RyanSquared

RyanSquared Nov 30, 2018

Additionally, could this instead use the "resume" spec (currently draft)? That might also make it easier on both clients implementing this protocol, and servers implementing "resume" if this is already implemented.

@ProgVal

This comment has been minimized.

Contributor

ProgVal commented Nov 13, 2017

This is a great idea and a good draft. As a client author, I really like how easy it will be for us to implement it.
Client-initiated is also a nice addition that could be useful in specific contexts.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment