Últimos Cambios
Mi estado actual en Jabber/XMPP: - jabberES - jabber.org

[CS] Protocol Proposal (Second Round :))

Última Actualización: 23 de Febrero de 1.999 - Martes

Message-ID: <3613749E.2922CC7D@argo.es>
Date: Thu, 01 Oct 1998 12:25:02 +0000
From: Jesús Cea Avión <jcea@argo.es>
Organization: Argo Redes y Servicios Telematicos, S.A.
To: clientserver@dal.net, coder-com <coder-com@undernet.org>,
        Lista IRCops ESNET <ircops@esnet.org>,
        Lista IRC Hispano <irc-cop@catalunya.net>
Subject: [CS] Protocol Proposal (second round :)
References: <3569FCF6.F6BB2F16@argo.es>

This is my second round protocol proposal. I have tried to read carefully ALL previous messages about muy original proposal. I hope that this time we can achieve a consensus, sort of.

This document doesn't represent a concrete lex o syntax structure. The syntax used is only used to ilustrate the protocol. If the protocol reaches "working draft" status, a concrete syntax will be proposed.

Take care with "MUST", "SHOULD" and "MAY" along the document.

C: Client
S: Server

• STATES:

  In any moment, a connection can be in one of the following states:

  • Client:

    • COMMITTED: The protocol negotiation is over or there is no negotiation at all.

    • POOLING: Client issued a capability poll and it's waiting for reply.

    • NEGOTIATION: Client issued a proposal to server, and waits for reply.

  • Server:

    • COMMITTED: The protocol negotiation is over or there is no negotiation at all.

    • CONFIRM: When the client proposes an acceptable feature combination, server agrees and start sending data using the new scheme. Nevertheless, since IRC protocol is asyncronous, client MUST inform to the server when to start receiving data with the new features.

  • State diagram:

    Server
    Server State	Event	New State
    COMMITTED	Proposal	COMMITTED (if NACK) CONFIRM (if ACK)
    CONFIRM	Proposal	INVALID
    CONFIRM	Client ACK	COMMITTED

    Client
    Client State	Event	New State
    COMMITTED	Poll	POLLING
    COMMITTED	Proposal	NEGOTIATION
    COMMITTED	Client ACK	INVALID
    POLLING	Poll answer	COMMITTED
    POLLING	Proposal	NEGOTIATION
    POLLING	Client ACK	INVALID
    NEGOTIATION	Server ACK	COMMITTED
    NEGOTIATION	Server NACK	COMMITTED
    NEGOTIATION	Proposal	INVALID
    NEGOTIATION	Client ACK	INVALID

• POLLING:

  A client can ask the "features" supported by the server, issuing the following command:

  C: Protocol POLL
  S: Protocol nick-1, compress-zlib-1, esnet:channel_service-1, esnet:chan_pack-1(4096)

  Server replies with the full capabilities it supports. Clients MAY issue a poll in any state. Clients don't need to wait for reply to send new commands.

• NEGOTIATION:

  Negotiation in asyncronous, and other commands can be issued along its duration. Nevertheless, the negotiation MUST be finished before a new one can start.

  C: Protocol nick-1, compress-zlib-1, esnet:chan_pack-1(4096)
  S: Protocol ACK (1)
  C: Protocol ACK (2)

  1. Server sends new information using the new scheme. Nevertheless, it continues to process input from client using the old one.
  2. Now server reads input using the new scheme

  Clients MUST "ACK" the protocol because they don't need to wait to send additional command. Nevertheless, the server MUST know where the new stream starts.

  This simple scheme can be complicated:

  • Unknown capability requested

    C: Protocol nick-1, compress-zlib-1, esnet:chan_pack-1(4096), efnet:XCV
    S: Protocol NACK nick-1, compress-zlib-1, esnet:chan_pack-1(4096)
    C: Protocol nick-1, compress-zlib-1, esnet:chan_pack-1(4096)
    S: Protocol ACK
    C: Protocol ACK

    Here, "efnet:XVC" is refused.

    C: Protocol nick-1, compress-zlib-1, esnet:chan_pack-1(4096), efnet:XCV
    S: Protocol NACK nick-1, compress-zlib-1
    C: Protocol nick-1, compress-zlib-1
    S: Protocol ACK
    C: Protocol ACK

    "esnet:chan_pack-1" and "efnet:XVC" are refused

  • Out of bounds requested

    C: Protocol nick-1, esnet:chan_pack-1(8192)
    S: Protocol NACK nick-1, esnet:chan_pack-1(4096)
    C: Protocol nick-1, esnet:chan_pack-1(4096)
    S: Protocol ACK
    C: Protocol ACK

    As you can see, "NACK" gives a "hint" about suggested "new round". That is, unsupported capabilities are not listed, and capabilities with invalid parameters are "fixed". Server can, also, "suggests" the use of a mandatory capability:

    C: Protocol nick-1, esnet:chan_pack-1(4096)
    S: Protocol NACK nick-1, esnet:chan_pack-1(4096), cookie-1
    C: Protocol nick-1, esnet:chan_pack-1(4096), cookie-1
    S: Protocol ACK
    C: Protocol ACK

    Nevertheless, each negotiation round MAY be independent; that it, clients are free to change their negotiations in each round as they wish.

• IMPLEMENTATION:

  An example implementation:

  • Client:

    The client has several structures:

    • CURRENT: Current link capability in use.
    • DEMANDED: Capabilities demanded; waiting for the server responde
    • IWISH: Capabilities client wish to use
    • IKNOW: Capabilities client understands (usually IWISH = IKNOW)
    • SUGGESTED: Capabilities the server suggested
    • LASTSUGGESTED: Capabilities suggested last round

    The steps are:

    1. CURRENT = current IRC
       LASTSUGGESTED = current IRC
       DEMANDED = IWISH

    2. Client sends DEMANDED

    3. If server ACK then
       client sends ACK
       CURRENT = DEMANDED
       END

    4. If server NACK then
       if SUGGESTED == LASTSUGGESTED then deadlock. Client give up

       Keep the current CURRENT.
       END

       LASTSUGGESTED = SUGGESTED
       Clear DEMANDED
       add any SUGGESTED in IKNOW to DEMANDED
       go to (b)

  • Server:

    The server has several structures:

    • CURRENTIN: Current link capability in use, client->server
    • CURRENTOUT: Current link capability in use, server->client
    • DEMANDED: Capabilities demanded by the client
    • IINSIST: Capabilities clients MUST support
    • IKNOW: Capabilities server understands
    • SUGGEST: Capabilities the server suggested

    The steps are:

    1. CURRENTIN = current IRCD
       CURRENTOUT = current IRCD

    2. Client sends DEMANDED
       if DEMANDED in IKNOW and IINSIST in DEMANDED then

       server sends ACK
       CURRENTOUT = DEMANDED (server sends using the new scheme)
       END

       SUGGEST = current IRCD
       if DEMANDED not-in IKNOW then

       SUGGEST = DEMANDED in IKNOW

       if IINSIST not-in DEMANDED then

       SUGGEST = SUGGEST + IINSIST + DEMANDED

       sends NACK SUGGEST
       END

    3. Client sends ACK
       CURRENTIN = CURRENTOUT (server reads using the new scheme)
       END

• RATIONAL:

  • Server-Server protocol:

    The proposal is asimetric; there is a client and a server. In server-server connections, the paradigm is different, since both systems are equal. You can't choose a client looking at the "initiator", since the connection could be started from both sides.

    In Undernet P10 the solution is simple: the client is the server with the higher numeric code.

  • Renegotiation:

    The proposal supports renegotiation. A client can renegociate capabilities any time, unless another negotiation is in progress. It's up to server coders to support it. A server can, for example, replies "NACK current capabilities" to additional client renegotiations.

    In fact, using this proposal and its asyncronous property, a client without lag or using timeouts if the server doesn't support "Protocol" command or the link is overloaded.

  • Namespace polution:

    To avoid name collisions, there are two capability types:

    • global: these capabilities are global to the IRC world. MUST be documented and approved globally. Usually, a global capability reachs this status from a previous successfull "local capability".

    • Local: Local capabilities are "global" to a given namespace. Coordination, then, is retricted to that namespace. Example: "undernet", "dalnet", "ircnet", "esnet", and so on.

  • Mutually exclusive capabilities:

    Some clients can demand mutually exclusive capabilities. That is solved "automagically" using the server NACK. Server MUST use it to solve conflict or to show its capability preferences.

  • Groups:

    In the previous discussion, groups were suggested as a medium to "pack" several options "inside" a single one, to save bandwidth and to increase speed. This proposal has no provision for that feature. Nevertheless it can be accomodated in the scheme without any change.

    We can predict a small capability number, since they must be supported by the client coder comunity. In any case, a future grouping scheme doesn't need any modification in this proposal.

  • Parameters:

    Some capabilities MAY have additional parameters, so this proposal makes provisions to support them (NACK "suggests"). Nevertheless, is up to capability programmers to decide if they need parameters or not.

Comments?

-- 
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

• Artículos IRC
• Internet Relay Chat (IRC)
• Artículos
• La Página de Jesús Cea Avión

©1999 jcea@jcea.es