On Tue, Oct 02, 2001 at 09:46:09AM -0700, Ian Holsman wrote: > On Tue, 02 Oct 2001 03:22:25 -0700, Greg Stein wrote: >... > > 3) the app manually adds sessions to a group because it knows that > > www1.example.com and www2.example.com are the "same" > > also it should have the possiblity of adding www1:80 www2:81 www3:82 > this caters for applications which can't scale to make full use of > a multi-cpu machine
Absolutely. > > The session group satisfies connection pooling and multiple IP returns > > for a hostname. > > > > Each session represents a logical connection to the server. Because of > > timeouts, the server closing the pipe, or whatever, the session spans > > connections. But a given session will only ever open one connection at a > > given time. > > I'm unsure of the difference between a 'connection' and a 'session' in > the above diagram. > I was thinking that the 'connection' would handle the > keep-alives/pipelines logic for a individual connection to a server. > or in other words the 'physical' connection. > Just wondering what stuff would be stored at the session level. The session object is responsible for creating the connection, and possibly recreating it if the connection is not persistent, if the server timed out, or some other kind of error requires a close/reopen. The connection really is quite an internal concept, but the session and connection concepts *are* different. One is logical, and one is physical. > you will also need to store some info on the server/port level, as > this is what the load balancer/pooler might use to get the next available > connection/session. That stuff goes into the session groups. >... > > 2b) serf_process(ctx) sees a socket has data on it, so it reads it, > > matches > > it with the appropriate request/response pair and shoves the data > > down an input stack. > > I'm just wondering if the input stack/ctx could be a state machine > instead of a thread per request, this would scale better I'm not suggesting a thread per request. It should be possible for the app to define the handling of a request. Handle them all on one thread or spin off separate threads. Dunno how a state machine really plays into this... Cheers, -g -- Greg Stein, http://www.lyra.org/
