eric writes:
>
> >
http://www.dolda2000.com/~fredrik/doldaconnect/protocol.html
>
> This is just my opinion but I give my reasons:
>
> Format:
> ======
> CRLF vs CR: I think using a single character (not only CR) as
> command separator is better because it uses less bandwidth but also
> because it is faster to search (only 1 byte to compare instead of
> 2) and commands can be splitted using a simple strchr().
Yeah... I just recently implemented a protocol parser for the UI
controller channel for my new client, and I just couldn't find a
really elegant way of handling CRLFs... I'm pretty much for that as
well. I'll change it in the spec.
> Quoting: That seems good to me but we must define how backslashes are handled
> when encountered inside double quote (ignore the \ and discard it or keep it
> working as outside double quote). I think backslash should work everywhere in
> the same way and more over, this will allow this "somewords\"otherwords".
That was precisely what I was thinking. I thought I had made that
clear enough? I'll look over my wording.
> Semantics:
> ========
>
> Roles: DC without this architecture is not DC
:)
>
> Word sets: I think commands should be case-sensitive (for faster
> comparison) but we should forbid commands having same
> case-independent values (like toto and Toto).
OK, I can agree to that; it has another reason as well. The ISO C spec
doesn't actually have a wcscasecmp function declared. When I checked
it out, wcscasecmp was a GNU extension to glibc. Therefore, that might
actually be a good idea in more than one way. So... uppercase or
lowercase? =)
In that case it'll have to be lowercase - easier to type. I'm sure
everyone agrees. I'll change that too.
> User identification: ok for me.
>
> Search criteria: we should also define the maximum number of reply a client
> can send.
That might actually be a good idea. However, I see that being part of
the search protocol, not the criteria. In my mind, that's not really a
matching operator.
> Context: I don't understand the need of context in a client, I think the user
> privilege should be only maintain in the hub. With my hub for example, it is
> possible to have more than one "level" of operator with more or less
> privilege (some op can "only" kick users but some others can also modifiy the
> hub configuration). On connect, perhaps the hub should send a list of all
> commands a client can send (IMHO, a bit heavy).
Yeah, I know the context concept is a bit heavy, but I think that it's
a good idea, nonetheless. That way, it will always be very clearly
defined which commands are valid.
The whole thing is that I want to stay as far away as can ever be
possible from the state machine stuff used in current DC
implementations. Like the current client-to-client protocol - if you
don't send the commands in the exact right order, the client will
simply stop responding. I think that's ugly and repulsive, and this
will more or less force people into building better implementations.
It also makes it easier to extend the protocol, as I stated in the
document. The client could request an extra context for some specific
commands, and if that context is implemented in the hub/peer, then all
is good, otherwise it isn't. It's a very clear way of doing it, in my
mind.
Please continue to have your say on this.
> References:
> =========
>
> DESC: someone still uses a 32bit integer to store the share ?
;)
Nah, I don't really think so. I just thought that some lesser
programmer might decide to make a DC implementation, so I wanted to
make it clear from the very start.
> About connection stage, I assume GUID is the first command you sent (correct
> me if I am wrong). Why not having the following connection establishment:
>
> 1: H=>C: the hub sends its ID (something like the GUID of the client but for
> the hub)
>
> 2: C=>H: the client sends its ID and its password simultaneously (I modified
> your "GUID ID" command into "GUID ID password"). Then we can do the full
> authentification in a single step and without error, thanks to the GUID of
> the hub
>
> 3: H=>C: the hub accepts an continue the process into "normal" mode or close
> the connection after a message.
Again, my utter goal is to avoid this state machine stuff. Such a
thing as a "first command" should not be defined. It is equally OK to
send any command that is part of the `identify' context, be it DESC or
GUID. The important thing is what should be done, not in what order.
Fredrik Tolf