RE: Design teams

[Sheer El-Showk <sheer@saraf.com>]

> number of http requests is separate from the question of whether they come
> over a single tcp connection or multiple.
>
> problems with having multiple tcp connections were the reason http 1.1
> permits leaving the connection open and the basis for the multiplexing and
> asynchrony of BEEP.

Your point is well taken Dave ... my experience comes from webserver
benchmarking ... I'll have to go back and take a look at what the
benchmarks were doing exactly.

>
>
> >   Most server
> >OSes have been optimized to handle high volumes of simultaneous TCP
> >connections
>
> Simultaneous connections between different machines are fine.
>
> The problem is when the connections are between the same machine.
>

True, the fact that this is generally a registrar-regyistry connection
(rather than 10,000 clients to one registrar) means that we can handle
multiplexing over a single connection but what I'm not convinced of is
that the problem hasn't already been handled in the more generic
many-to-one case.  That is, if a server can handle 100+ simultaneous
connections from different clients then why try to rework this so the 100+
connection are now done in a single connection to a single client (we can
just have a 100+ connections to a single client).  That's just a "why
reinvent the wheel" argument; there's another that you brought up (perhaps
inadverdantly).  BEEP has some strong arguments in a one-to-one connection
environment (roughly B2B without throwing too many catch phrases around),
which is generally the case in registry-registrar.  But as a _generic_
registration protocol, whose to say I might not allow hundreds of
different clients to connection from different locations (without going
through some front end registrar).  In this case the overhead of BEEP and
the associated advantages (suddenly asynchrony is not that useful) must be
weighed very differently.  I don't think our protocol can solve all
problems and work well in every case, but, in a case like this, where we
can move some of the _optional_ functionality (asynchrony, encryption,
etc...) into other layers and propose certain minimum requirements
for those layers then I think we would be well advised to consider it.

> Leaving the connection open is helpful, yes.
>
> We should note that the term light-weight is probably misleading, since
> most of the features in BEEP are present in most connection-based Internet
> applications.  If BEEP is not used, the features will be provided in some
> other way.

True, but they are often implemented by multiple tcp connections with SSL.
The current NSI RRP setup is not asynchronous (as far as I know).
Channels can be preserved using a group of long-lived TCP connections with
login and logoff commands (ie multi-session connections to avoid SSL
handshake overhead).

I'm not trying to argue in circles ... yes I think BEEP is neat and I'm
not really that worried about its performance (though I havn't really
looked at it enough to say).  My real concern is that the protocol relies
too much on an underlying BEEP session and then becomes unimplementable
over very different transporst like SMTP.  If this concern is addressed
then BEEP vs TLS+multiple connections is really not that big a deal as far
as I'm concerned (though then it really doesn't belong in the protocol as
anything other than a recommendation because our protocol becomes unaware
of that layer and doesn't rely on it).

Regards,
Sheer

>
> d/
>
>
> ----------
> Dave Crocker   <mailto:dcrocker@brandenburg.com>
> Brandenburg InternetWorking   <http://www.brandenburg.com>
> tel: +1.408.246.8253;   fax: +1.408.273.6464
>