Re: FW: Number of connections

Carlos said:
]
] How does the client signal, after being continuously pushing requests
] into the pipe, that it doesn't want anything else ?

I'm not sure I understand the question.  I think the answer is that 
when the client has no more requests to make, and has recieved all the 
responses it wants to wait for, it closes the connection.

]I don't see the need
] for multiplexing in the client->server direction, if the client can
] seat there and bomb the server continously with requests.

I agree that it isn't very useful in the client->server direction.  And 
actually, it doesn't work in the client->server direction.

I tried to indicate that by syaing "the client requests..." by sending 
Request-ID with an ID and optional stream number. I meant that 
strictly, as in the browser talking to the origin server or  proxy 
cache, or proxy making requests to another proxy or origin server. I 
would have said "sender" otherwise.  However, I agree that it is a 
little unclear.

It doesn't work because the server can't tell whether
	Request-ID: xxx, stream=n
means that the client wants the response entity-body on stream 'n', or 
that the client wants to send the reuest entity-body on stream 'n'.  I 
am pretty sure that this restriction could be lifted, but it didn't 
seem worth the trouble at the time. Thinking about it some now, something like
	Request-ID: xxx, instream='n', outstream='m'
should work if there were agreement that there was need for 
client->server direction multiplexing.

]
] The scheme seems really useful for the server->client direction of the
] connection. This would allow different programming paradigms for the
] server, like spawning a thread for each request that comes from the pipe, or
] using overlapped I/O and pushing chunks back into the pipe as the
] file I/O operations end, or whatever.

Yup... and it doesn't waste net resources with extra connections.

]
] > To recall what chunking does: each chunk starts will the length encoded
] > as an ASCII hex number, followed by CRLF followed by the next chunk of
] > data as 8 bit raw octets, followed by CRLF.  The last chunk has length
] > 0, and after it can optionally come entity header fields (other than
] > Content-Length or Transfer-Encoding).  The idea is that the receiver
] > can reliably detect end-of-data, without having to know in advance what
] > the content length is, so that the server can dynamically generate it
] > and send early parts of it while the later parts are being generated.
]
] I wonder why end-of-data detection wasn't introduced in the protocol
] previous to this discussion (for single request/response sequence on
] a connection), instead of leaving this detection to
] the socket interface.

End-of-data detection, via chunking, is in the 1.1 draft. Its 
simplicity and ease of extension sparked the awareness that 
multiplexing was just a very small additional step.

Paul

Received on Friday, 16 February 1996 09:22:41 UTC