Todd Pederzani writes:
> Fredrik Tolf wrote:
> > >In any case, I don't really know why I even followed up on the DoS
> >matter. The thing that I really don't agree with about ADC is the fact
> >that such a command division isn't actually necessary. I believe that
> >all commands should be clearly defined, and those that are broadcasted
> >should be specified in such a way that allows for easy future
> >extension of those commands.
> > True, this is a better argument than a half-hearted > DC-client-as-ddos-tool argument (but that should be a topic of > discussion at some point - how to handle "evilness" in the network).

Yeah, I think that should be the subject of a later
discussion. Possibly not at all on this list, since it's probably not
a protocol matter.

> For me, ADC makes sense: The simplicity of, more or less, being
> able to write a hub that consists of a switch statement is
> appealing.  So is the ability add arbitrary broadcast and directed
> commands.  Users want a lot of things, and all of them won't be
> covered by any single protocol we accept.  If a new directed
> command is needed (say, for client to client cctp), making its
> function dependent upon what (adc or dolda-connect compliant)
> hubsoft the clients are attached to is just plain unacceptable -
> it's the same situation we have now.

I do agree with you in a way, in that it does seem appealing in terms
of simplicity. However, I don't think that kind of simplicity is going
to hold, since the broadcast commands still often require some
individual intelligent processing by the hub. For example, the only
two commands in ADC that truly benefit from broadcasting are, as far
as I can see, the SCH and INF commands. These already differ in my
mind, in that if the hub receives to SCH commands too close in time to
each other, it should reject the second one with an error. However, if
it requires two INF commands within one "allowed broadcast period", if
you see what I mean, it shouldn't deny the second one. It should wait
until the broadcast timer expires, and accumulate all succeeding INF
commands and then re-broadcast the final data once the client is
allowed the broadcast bandwidth again, right?

Do you see what I mean, or were I too unclear?

Fredrik Tolf