Skip to content
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
Choose a base branch
from
Open

Add migrate extension #330

wants to merge 1 commit into from

Conversation

aji
Copy link

@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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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*
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

and address of the new server

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The previous text should have a title Server-initiated migrations

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Where to find such name?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
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.

@DanielOaks DanielOaks mentioned this pull request Nov 6, 2018
@jesopo
Copy link

jesopo commented Feb 15, 2019

Huge +1 for this spec - seamlessly being able to push people off a leaf so it can be rebooted is a very cool idea.

That said, I really think this should be changed to leverage resume (#306) instead of having 2 systems that use "resume tokens" (that might mean that the wording for resume needs to change to "servers MUST allow cross-server resumption" - at least when combined with this spec.)

@k4bek4be
Copy link

This discussion looks dead for now. What about standarizing JUMPSERVER instead (or additionally)? It uses 010 RPL_REDIR as :irc.some.net 010 nick otherserver.some.net 6697 :Please use this Server/Port instead and looks like some clients and servers already support it. Won't be so seamless but easy on both sides. Only somehow make it aware about different kinds of connections (TLS, websocket etc).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants