httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chuck Murcko <ch...@telebase.com>
Subject Re: An idea for state saving
Date Fri, 31 May 1996 17:02:01 GMT
Robert S. Thau liltingly intones:
> 
>   Yes indeed. The classic multiplexer approach. It *is* tricky, but
>   least expensive from a hardware standpoint, generally speaking.
>   You put your $$$ into one (or several) extremely fast channels to
>   the back end database engine.
> 
> Ummmm... I thought we were talking about software architecture, not
> hardware architecture.

Yes, and I'll let the discussion return to that. I was only trying to
point out that software shouldn't be the only solution considered to
a problem such as this. My apology for the divergence.

> If your pipes to the back end are ethernet,
> FDDI, or heck, even fast serial lines, you can run TCP on them, open
> a separate TCP virtual circuit for each client process (a/k/a "socket"),
> and let the kernel sort out who gets what, with no fuss and bother at
> all in the server software.  Or, I suppose, you can open the raw device,
> talk at it directly, and sort out the mess yourself... but in the end,
> you're likely to wind up reinventing at least the IP layer, and quite
> possibly winding up with more overhead than if you'd used the IP layer
> you already had.  I *think*... assuming of course, that we are in fact
> both talking about the same thing in the first place.
> 
Well, you'd only rewrite the network layers if you were going to try to
squeeze the absolute last iota of performance outta da link. The proof
of concept model would doubtless use TCP, and get deployed anyway 'cause
there'd be no time left in the schedule to do the superduper link model.
8^)

chuck
Chuck Murcko	N2K Inc.	Wayne PA	chuck@telebase.com
And now, on a lighter note:
If you think the problem is bad now, just wait until we've solved it.
		-- Arthur Kasspe

Mime
View raw message