		*Últimos Cambios*
	Blog personal: El hilo del laberinto

[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

Más información sobre los OpenBadges

Donación BitCoin: 19niBN42ac2pqDQFx6GJZxry2JQSFvwAfS