FWIW, I tend to think of a server (web server or otherwise) as being
upstream also.
Though I guess water flow is a poor analogy in general, since the
bytes do "flow" both ways. Maybe "upstream/downstream" can only be
meaningful with respect to a single packet of bytes: they always flow
downstream: so the sender (client or server) is upstream and the
recipient is downstream.
Of course, this is all probably non sequitor to your actual question,
and it doesn't appear that the author of the comment was thinking this
way.
:-)
-billo
From: Bill Stoddard <[EMAIL PROTECTED]>
Date: Tue, 08 Jul 2003 10:39:39 -0400
Perhaps I am being silly, but do we need to standardize on a definition
of 'downstream' and 'upstream'? Here is a comment from proxy_http.c:
/* Note: Memory pool allocation.
* A downstream keepalive connection is always connected to the existence
* (or not) of an upstream keepalive connection. If this is not done then
* load balancing against multiple backend servers breaks (one backend
* server ends up taking 100% of the load), and the risk is run of
* downstream keepalive connections being kept open unnecessarily. This
* keeps webservers busy and ties up resources.
*
* As a result, we allocate all sockets out of the upstream connection
* pool, and when we want to reuse a socket, we check first whether the
* connection ID of the current upstream connection is the same as that
* of the connection when the socket was opened.
*/
If I am reading this correctly, my polarity must be different that the
author of this comment. The way I look at it, most bytes flow from the
webserver to the web client. Analogous to water, the bytes flow
'downstream' from the server to the client. Now a proxy maintains two
connections, one to the client and one to the webserver. I would call
the connection from the client to the proxy the 'downstream' connection
and the connection from the proxy to the server the 'upstream'
connection. What say you?
Bill
