> In a very early protocol draft, I had a transaction identifier in
> the packet so that clients could pipeline requests to
> a server that, in theory, could be processed and responded
> to out of order.
>
> However, it was decided that requests over a single
> connection would be processed in order (FIFO), and that
> if overlapping requests are desired, then the client could
> open additional (separate) connections to the server and
> issue them.
Yes, I recall this situation. I thought your proposal to
include a transaction id was very well founded, and reflected
many, many protocol designs in use today.
It bothers me, though, that the decision is to just "open
another connection" (or two, or three) if the client wants
to perform parallel actions. IHMO, this is far worse in
terms of resource utilization than simply using a transaction
id.
...jay
----------------------------------------------------------------------
-- JK Martin | Email: jkm@underscore.com --
-- Underscore, Inc. | Voice: (603) 889-7000 --
-- 41C Sagamore Park Road | Fax: (603) 889-2699 --
-- Hudson, NH 03051-4915 | Web: http://www.underscore.com --
----------------------------------------------------------------------