- From: Scott Lawrence <lawrence@agranat.com>
- Date: Thu, 06 Aug 1998 20:27:42 +0000
- To: HTTP-NG Comments <www-http-ng-comments@w3.org>
1. Reserved Session IDs (nit)
> Each session is allocated a session identifier. Session
> Identifiers below 0 and 1 are reserved for future use.
The declaration of the w3mux_hdr session_id field declares it as
unsigned; given that, what is the meaning of 'below 0'?
2. Session ID allocation
> Session IDs allocated by initiator of the transport TCP connection
> are even; those allocated by the receiver of the transport
> connection odd.
The 'initiator' of a TCP connection is ambiguous; TCP connections
may be created by a simultaneous open in both directions - both
parties see themselves as the initiator. Not an issue in current
HTTP usage, since HTTP/1.x servers don't create connections, but a
problem if this is to be a general purpose protocol.
Even in the HTTP case one can easily envision that this could be a
problem for hierarchical proxies:
client <-1-> proxy-A <-2-> proxy-B <-3-> server
Picture an architecture in which proxy-A and proxy-B are configured
to know about each other (B may be the only way A can go - it exists
to save bandwidth on slow link 2) and bring connection 2 up
immediately when they initialize.
I'm also not clear on how session ids are selected by one party when
in the section on Endpoints the draft says:
> To establish a new session, the initiating end sends a SYN
> message, allocating a free session number out of its address
> space.
and in the section on End Points:
> A MUX protocol ID only identifies a MUX channel relative to a
> particular "endpoint". The pair of <endpoint><protocol ID>
> completely identify a MUX channel, without regard to IP address,
> TCP port, or other information. Endpoint IDs are URI names for
> endpoints. Any endpoint may have multiple endpoint IDs. We do not
> place any further restrictions on the types of URIs that are used
> as endpoint IDs.
... if the endpoint is not dependant on "IP address, TCP port, or
other information", then how do I know whether or not a given
session id is available at the other end?
It may be that I'm being confused here by the lack of a definition
for the term 'MUX channel', and the fact that an 'Endpoint' is only
defined in terms of the messages that describe it. What exactly is
an 'Endpoint' and how does it relate to what in other protocols is
described as a Service Access Point (that is, some identifier
provided by a lower layer to an upper layer)?
3. Flow Control
The initial credit per session is given as 16K bytes; in memory
constrained environments that may be large enough to trigger the
deadlock scenarios you describe in the introduction.
The SetMSS message sets the maximum fragment size across all
sessions - wouldn't it be better named SetDefaultMFS? and might it
be usefull to have a SetMFS that applied only to the session it is
sent on?
Similarly, I don't see a definition for the maximum allowed fragment
size at the start of a connection.
Why are AddCredit and SetDefaultCredit described as R->T rather than
Both? Either party may be a receiver.
4. What are the appropriate strategies for determining if the WebMUX
protocol can be used?
Shouldn't this just be a (new) well known TCP port? WebMUX already
includes a mechanism for describing the next layer above it. HTTP
servers that support http over mux would listen on both 80 and the
new WebMUX TCP ports.
This leaves open the problem of discovery by clients that the WebMUX
is available, but we could define a new HTTP response header to be
returned (I can't think of a currently defined one that meets the
need) to indicate the availability of mux as an alternative for
subsequent requests.
We could define a new response code 102 WebMUX; if the server had
WebMUX available on its well known port, it could return '102 CRLF
CRLF' before the final response when a request is received on port
80; 7 bytes overhead that allows the client to discover the
availability of WebMUX for subsequent interactions with that server.
Upgrade could also be used to switch an existing HTTP connection
from HTTP to WebMUX if the client indicated readiness to do so by
sending an 'Upgrade: WebMUX/1.0' request header.
5. Message Formats (nit)
It always makes me nervous to see wire protocol message formats
expressed as C structures - C compilers don't translate them
uniformly to bits on a wire.
Here is my rendering of the two header formats in graphical form.
Data Message
8 1 1 1 1 1 1 18
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |S|F|R|P|L| |
| Session Id |0|Y|I|S|S|N| Fragment Size |
| | |N|N|T|H|G| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
32
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Long Fragment Size (present only if LNG == 1) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Control Message
8 1 4 1 18
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |L| |
| Session Id |1|Control|N| Fragment Size |
| | | Code |G| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
32
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Long Fragment Size (present only if LNG == 1) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
--
Scott Lawrence Consulting Engineer <lawrence@agranat.com>
Agranat Systems, Inc. Embedded Web Technology http://www.agranat.com/
Received on Thursday, 6 August 1998 16:26:51 UTC