Re: keepalives again

> 
> Hi all,
> as I see we can divide and conquer w.r.t. keep-alive.
> The divison can be done by separating the connection-dependent (persistent
> http related) stuff from unrelated client-server states.
> For the first half, we have the max and timeout question.
> The MAC/TCP problem mentioned by Beth Frank reopens the question (for me),
> but not knowing the details we can't go forward.
> -- 3 days later: according to Roy's suggestion: what is the real difference
> between the TCP abort and TCP close on MAC?
> The problem seems not being http specific. How this problem is solved in other 
> TCP/IP based protocols/applications? Discussing this with MAC developers may 
> help. Who knows the MAC guys?

The MAC Mosaic guys are going to run some tests to determine exactly what
does happen on close vs. abort.  Their off the cuff guess is that abort
doesn't send a close connection message, and the server only finds out
the connection is broken when it trys to read from the socket next.

> For the second half of the problematics (the state/context ascpects) we have
> different domain. Contexts/states can be keept indepently from TCP connections.
> (Authentication contexts are a special case, however they can be keept using a 
> more complex technique. Persistent TCP connections help here a lot, but still
> don't solve the problem completely.)

We've been warned repeatedly by our security guru that persistent TCP connections
can by hijacked by unauthorized users without much difficulty, so there are different
constraints on an authentication session than on an open (insecure?) session.

> The Accept-signature concept originally wasn't tied to persistent connections.
> In the accept sense there are 3 contexts for a browser:
> 1. web page
> 2. inline (character based apps like lynx never use this context.)
> 3. download (Accept */*)
> We should implement some feature, enabling easy switch between these contexts.
> The other context type is the authentication context. Proxies, multiplexing
> many clients to a server somehow should be able to change this context too.
> To discuss this, we should consider first the proxy authentication problem.
> (how the authentication done by the proxy can be propagated?)
> And there may some other contexts to exist. Which other contexts should be
> supported in 1.1? 
>
> Andrew. (Endre Balint Nagy) <bne@bne.ind.eunet.hu>

-- 
		Elizabeth(Beth) Frank
		NCSA Server Development Team
		efrank@ncsa.uiuc.edu

Received on Wednesday, 25 October 1995 14:32:59 UTC