Últimos Cambios
|
|
|
|
Últimos Cambios |
|
|
|
||
| Mi estado actual
en Jabber/XMPP:
| |||
Última Actualización: 23 de Febrero de 1.999 - Martes
Message-ID: <3581675D.C471D2CC@argo.es> Date: Fri, 12 Jun 1998 17:37:33 +0000 From: Jesús Cea Avión <jcea@argo.es> Organization: Argo Redes y Servicios Telematicos, S.A. To: clientserver@dal.net Subject: [CS] Delayed Replies (was: Protocol Proposal)
I apologize for the delay. I'm having a very stressing time these weeks working on my taxes :) and coding for ESNET.
I'm answering ALL the thread in an unique message. I apologize. I'll try to be... constructive.
I'm quoting a lot. I know. I'm trying to write an understandable message.
> Why do you believe TELNET's protocol is cumbersome ? Experience has
> shown that it is very hard to write a broken TELNET client. I'm not
> sure the same can be said for PPP...
If you understand spanish (you can use Altavista's babelfish if you don't) you should check my degree project for the university, at http://www.argo.es/~jcea/proyecto/. I've implemented PPP and Telnet protocols. You can value my words, Darren.
In any case I'm not asking to implement PPP, but a PPP-procedural-state like scheme.
> Also, TELNET has "sub options". Your proposal doesn't.
Errr... Fine. Since clients demand ONLY options they know, grouping is not an issue for the network. It doesn't save anything.
> me: DO efnet
> server: WON'T efnet, WILL undernet
> me: DO undernet SUBOPT ts
> server: WILL undernet SUBOPT ts
You could do also:
C: protocol efnet:ts
S: protocol !efnet:ts
C: protocol undernet:ts
S: protocol ACK
Or:
C: protocol efnet:ts undernet:ts
S: protocol !efnet:ts undernet:ts
C: protocol undernet:ts
S: protocol ACK
I don't see benefits using grouping. In fact you can query server about network known options.
> Please note that this list is not intended to discuss the features
> itself (that could or can be negotiated) :)
Of course. First we need to define a negotiation protocol. Options available are not the current issue.
> | 2. It sends a "protocol" message asking several features.
>
> This sounds indeed most logical, although then we need to agree
> on the Hack/Kludge that when a server responds with "PROTOCOL: unknown
> command" (or "Register first") that the client will conclude that
> no protocol negotiation is supported and that it has to fall back
> to the default, being the current protocol (anno 1997/1998).
Really you don't need any special hack. It's a direct effect. Clients can issue a "protocol" negotiation when:
1. There is no negotiation in progress (initial connect).or
2. Server answered the last "protocol" challenge, accepting it or denying it.
So if a client issues a "protocol" and the server doesn't support negotiation, it never responds and client uses the current client-server standard.
So the protocol used along a link lifetime can change several times. Clients request features, but only switch modes when the server reply "ACK". There is a problem here: this scheme runs fine in the downlink but server DOESN'T know when the client has received its "ACK". Most of the time this is not a problem, since most protocol options are only available at server -> client direction (for example, timestamps). The bidirectional options (ej compression) can be solved using a special tag in the client -> server direction or restricted for the downlink only (you usually receives a lot and sends little :).
IRC is a "almost" asyncronous protocol, and I'm trying to keep it in that way :).
You can forget the problem if the client answers the server ACK with another ACK.
> | 3. Options unknown by the server are refused. Parametriced modes
> | with invalid params return "suggested" values. Mutually
> exclusive
> | modes are rejected, keeping "best" option (see example below).
> |
> | 4. Client changes its "protocol" demanded string and go point 2
>
> What is the benefit if this approach in comparision to when the server
> first tells with features it supports ? I can think of the follow
> benefits in favour of the later method:
Fine. The server can send a "protocol" line along the initial registering, like the MOTD.
A reject mecanism can be useful if a network chooses to support mutually exclusive options. For example, you can choose compression and crypt, but not simultaneously, to keep CPU resources low in the server. For example.
But "advertise" protocol when registering is a election. Nice.
> 3. Assume that there are 1000 IRC networks and 10,000,000 features,
> then wouldn't it more logical to first ask the server what
> he supports ?
In my proposal you have a "protocol *" command which lists all the options known for that server. Although you can "remove" that feature and "advertise" the options in the connection, like MOTD, I'd like to can ask again (like when you write "motd" in your IRC client window.
> I am not saying it is impossible to let the client start, I am just
> saying that I think it would be less complex to let the server start,
> and then continue as in your proposal.
Complexity is equal. Negotiation has no state until you finish it. That is, server only responds "protocol" request from clients, doesn't keep any state UNTIL options requested can be fullfitted. The same for client.
> The above example would become:
> server->client "I support A and B"
> client->server "gimmi just A"
Fine.
> The rest of your post looks pretty good. I just have a few
> general thoughts I'd like you to think about (brainstorm):
Nice, nice :).
> 1. Does it make a difference that we have many IRC networks who
> will probably mainly support features that are only available
> on their own network ?
[...]
> that tells the client which network it is connected to. (ie
> "NETWORK esnet"). That should reduce the bandwidth needed for
> the negotiation considerably.
I see your point. Nevertheless I don't see a risk. The client can ASK ("protocol *" or your "MOTD" like scheme) the network about available options. And from them, client chooses.
> 2. What kind of support can we builtin for "grouping" of features ?
> I suppose that in 10 years a LOT of features are always used
> together, and probably even mandatory the default. It would be
> short sighted not to have a possibility to shift the origin of
> the negotiation start somehow.
Uhmmm... Something like "protocol undernet:*"?. If you use a "*" in your request, server responds only with options matching.
In the future you'd have "macro options". That is, options which include other. For example:
C: protocol *
S: protocol esnet:zlib esnet:crypt-blowfish64
C: protocol *
S: protocol esnet:zlib esnet:crypt-blowfish64 esnet:secure
If the client do:
C: protocol esnet:secure
S: protocol esnet:secure ACK
the link can be compressed (zlib) and crypted "automagically". That is, "esnet:secure" includes the other two.
[Grouping]
> Instead it seems more logical to allow to group features (using
> a & sign) and then assign a priority to it.
>
> For instance:
>
> MACRO abc = aaa & bbb & ccc
> MACRO def = ddd & eee & fff
> MACRO ade = aaa & ddd & eee
> MACRO foo = abc | def | ade
> DO foo
>
> meaning that you prefer 'abc', but if that is not possible,
> you want 'def' - and only when that is not possible, you
> want 'ade'.
You can achieve the same using a multiple round negotiation. And you don't need to keep any state, either :).
> Don't take
> everything too literally - its the idea behind that is important.
> Wether we use multiple lines, or put everything on one line,
> wether we use binary stuff, or english words - I don't care at
> all at this point in the design.
I agree. We are talking about an abstract mechanism here. The time to be concrete is far away yet :).
> The point is you want to give meaning, within the protocol, to words
> which are really parameters. What if EFNet wants to add a feature
> called
> "undernet" ? How does "C: efnet undernet" read then ? At least if
> you have a syntax like "DO newircnetprotocol" it makes sense for an
> error to say "999 newircnetprotocol :unknown protocol". Makes life
> much clearer than "333 newircnetprotocol :command unknown".
Local features should be prefixed. In your example, feature would be called "efnet:undernet". This is mandatory in order to reduce namespace pollution.
Sintaxis could be:
option [":" suboption] ["(" parameter ["," parameter]... ")" ]
If the server doesn't know about "protocol", it responds "333 protocol :command unknown". If it doesn't support the option, it responds "protocol !newircnetprotocol".
For example:
protocol linelength(512)
protocol zlib(32768)
protocol esnet:nick
protocol undernet:compress(4096)
In any case, like Carlo says, we are not defining syntax just now. Only a way to understand the protocol.
> > Why only allow to negotiatie booleans ? Why not also integers ?
>
> Because the aim of this is to develop a procedure and understanding of
> how to negotiate which protocol features the client understands. The
> length of a line is not something I'd consider a protocol feature. It
> would be like deciding you wanted to negotiate control characters or
> something. Within the context of IRC these parameters are well
> defined and changing them has major implications for any sort of
> interoperability.
Yes, linelenght is a bad example. But sometimes you need to negociate integers. For example, if you are negociating compression, you'll want to negociate tablesize or key lenght (for crypto). Just an example.
> > For instance, if 'foo' has suboptions foo1 an foo2, and 'bar' has
> > suboptions 'bar1' and 'bar2', then why can't a server and a client
> > agree to do both, foo and bar?
>
> Because it doesn't make sense for anyone.
>
> A server should, IMHO, be dedicated to a single protocol.
Absolutely not! :). The basecode for ESNET is Undernet IRCd, but we have a lot of "patches". Perhaps some day dalnet defines a nice feature (let's say "anonymous users") and we'd like to use it in our network. So we could have:
C: protocol *
S: protocol zlib(4096) undernet:nick esnet:database dalnet:anonymous
Our server accepts "zlib", a standard link compression for most IRC networks :), undernet extensions (nick), our own patches (esnet) and a foreigh feature (dalnet anonymous).
Yeah, I could patch my server to reply "esnet:anonymous" instead of "dalnet:anonymous". But is not serious to rename a feature only because I dislike the word.
Time later "dalnet:anonymous" becomes a standard feature in IRC and my server would respond:
C: protocol *
S: protocol zlib(4096) anonymous undernet:nick esnet:database dalnet:anonymous
I don't delete "dalnet:anonymous" because not upgraded clients would use it instead of "anonymous". Both features are the same, really, equivalent. In two years I'd delete "dalnet:anonymous", perhaps };-)
> Namely, when each feature has a life cycle:
> 'added/optional', ['mandatory', 'optional',] 'removed'
> (and two protocol/versions are not compatible when any
> option occurs in one protocol/version as 'mandatory'
You are worried about option proliferation, aren't you?. Are you really thinking about hundred of options (in a single network) in a near future?.
As I said previously in this message, and you wrote in yours, in the future you would "group" options in a single one. But I disagree in a single thing: If you negociate such option, you must support it fully. You'd can't disable a suboption.
That is, if in three years you define a "undernet:undernet1" option and it "groups" previous options like compression, crypt, stamps, anonymous, etc., you can't do "I choose undernet1 *BUT* I don't want compression".
Since "undernet1" is a new option, if you choose it, you *CHOOSE* it :).
--
Jesus Cea Avion _/_/ _/_/_/ _/_/_/
jcea@argo.es http://www.argo.es/~jcea/ _/_/ _/_/ _/_/ _/_/ _/_/
_/_/ _/_/ _/_/_/_/_/
PGP Key Available at KeyServ _/_/ _/_/ _/_/ _/_/ _/_/
"Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/
"My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibnitz
