[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: OCP transport nomination
On Fri, 25 Apr 2003, The Purple Streak, Hilarie Orman wrote:
> While re-use is certainly expected, we shouldn't make the overhead
> so high that it becomes impractical to open many connections.
> Separate connections might be needed to keep sensitive user data
> encrypted under different keys, multiple connections might be
> desirable for scheduling streaming applications, etc.
Support for separate connections is a MUST, of course! The overhead we
were talking about is in the connection _establishment_ phase. The
overhead to keep a connection open is usually much smaller and is less
important as far as response time or bandwidth is concerned. The
reason to choose UDP over TCP is usually not the number of concurrent
events (connections or queries) but the cost of creating an event
(opening a connection or sending a packet).
> On Fri, 25 Apr 2003 at 14:32:35 -0400 Markus Hofmann observed:
> > Alex Rousskov wrote:
> > > Do we expect the set of callout servers to change so rapidly that
> > > server connections cannot be reused at the OPES processor? If yes, we
> > > may have to support UDP-like OCP transport (and probably change a lot
> > > of OCP requirements related to "OCP connections"). If no, then
> > > transport connection setup time is not an issue and TCP-based OCP
> > > transport should work as well (or better) as UDP-based one. I think
> > > the latter is much closer to reality. Am I missing something important
> > > here?
> > No, I don't think you're missing anything. You summarized very nicely
> > what my understanding has been for a while. Since we expect to
> > "re-use" estbalished TCP connections between OPES processor and
> > callout server, the TCP connection establishment overhead is probably
> > not of big importance.