RE: Design teams

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

> Thank you for providing the glinching reason to use beep:  multiplexing
> data streams over a single connection.  (Multiple TCP connections cause
> problems.)

How so?  I brought this up before but I was persuaded by BEEP's other
facility, namely asynchronous messages which allows for more efficient use
of a single connection.  What I said then was that TCP (the protocol
and the implementations) has a proven record  of handling multiple
connection with very high volume (even a low end  server can handle a very
high volume of http requests per second) simultaneously.  Most server
OSes have been optimized to handle high volumes of simultaneous TCP
connections and a lot of research has gone  into this (certainly beyond
the scale we should be considering since I think web servers exist
that support much higher load than most registries can expect -- their
bottleneck will be in the server business logic, not the tranport
protocol).

I still think BEEP can help us in many ways; in particular it can undercut
the high cost of initiating a _secure_ connection (very slow) by allowing
us to reuse an existing connection for multiple sessions/transactions
(depending on the nature of the protocol we design) in a non-blocking and
standardized way (ie not re-inventing the wheel).  If secure connections
were not a concern I would not be convinced that relying on
simultaneous light-weight  TCP connections with no multiplexing would not
be the right way to go.

Sheer

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