Protocols (Was: HTTP)
nbastin at opnet.com
Wed Dec 11 12:42:08 PST 2002
At 12:16 PM 12/11/2002 -0800, you wrote:
> > >> Basically, a box can only maintain a certain number of active
> > >> connections given it's stack implementation, and in the case of mostly
> > >> idle connections, having them on the waitqueue limits the number of
> > >> new connections you can handle, even if they're not doing anything.
> > >
> > >do what every other protocol in the world does: timeout after X seconds.
> > ARRGGGG! You say that the protocol should timeout, yet you say that HTTP
> > closing the connection is a bad thing???? HTTP is just accelerating the
> > obvious in this scenario - the connections will always timeout, so why not
> > just close them and be a good citizen?
>even open an ssh connection?
>how about an ftp session?
What? We're talking about web apps here - what does it have to do with ssh
or FTP? HTTP closes the connection because the largest percentage of the
time is going to be in idle anyhow, which would cause a timeout. What do
ssh and ftp have to do with it?
> > And I submit that we're talking about protocols, and not application
> > implementations, and that you are blaming the protocol for the sins of
> > users.
>not the users, the application developers that abuse http. i do not
>blame http. i blame the application developers.
Well, it appears that there are some in this thread who feel that HTTP is
evil and bad (and somehow it's use of TCP, although I can't even fathom the
reasoning behind that), because of specific applications which are bad.
> > No, it isn't. It may reimplement a tiny component of what TCP gives you,
> > but TCP isn't giving it to you for free. The price of using the trust you
> > get from TCP is that you have to leave the connection open, and that is
> > expensive.
>and the mysql database is cheaper? hmm.
Possibly, yes. Besides, the mysql data could be clustered and load
balanced and thus you could very easily use less resources rebuilding the
state than keeping the connection open. These are all tradeoffs, as I said
before. If you have an application which will not spend the majority of
its' time in idle, then you shouldn't close the connection, but if you app
is spending most of its' time in 'user think time', closing the connection
and freeing up server resources makes sense.
> > "We're giving away a free, full featured Operating System." "No thanks,
> > I'd rather pay for a RtOS that's optimized for my purpose and not as heavy
> > as your full-featured Operating System".
>you forgot to add:
>i want to pay for that RtOS that's optimised, but has left out some very
>important key components. i will happily re-implement those components
>that i see that your Full Featured OS has, but i know RtOS, so i willpay
Full featured OS is really heavy and can't run on my hardware, but it has
one feature I need. I'll implement that specific very small feature on
RtOS, and thus be able to use it.
TCP is very inefficient if you're not sending any data over a connection,
but are keeping it alive. So, to get around this problem, when we are done
sending data, we close the connection. When we want to send more data, we
open a new connection.
What you are saying is like suggesting that FTP keep the data connection
open even after it's done transferring the file because you might want to
send one again in the future. It's more efficient to close the data
connection and open one again when it is indicated the the user wants
More information about the KPLUG-List