RE: Design teams

[Dave Crocker <dcrocker@brandenburg.com>]

At 06:14 PM 3/21/2001, Sheer El-Showk wrote:
> > Thank you for providing the glinching reason to use beep:  multiplexing
> > data streams over a single connection.  (Multiple TCP connections cause
> > problems.)
>
>...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.

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.


>   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.


>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.

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.

d/


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