Re: APPLCORE: An architectural question

> > That's not an alternative.  The mere availability of a message muxing protocol doesn't relieve the higher layer of the responsibility of deciding how to use it.  This is a matter of the software in the peers, not the wire protocol (although the design of each naturally influences the design of the other).

> I heartily agree that if webmux or another message multiplexing protocol is available, an application layer protocol like XP doesn't need any request/response tagging mechanism.  You just use multiple connections for everything instead of only when you explicitly want concurrency below the level of whole responses.

Actually, that's just one way of deciding how to use the mux's services; I can imagine others.  For example, you might still want to: distinguish requests from responses, so that each side can be a client of the other; put request/response IDs in the messages (at the request/response layer), so you can admit the possibility of more or less than 1 response per request; and/or have additional message types, such as "interrupt" and "clean shutdown".  And there's a whole other raft of issues involved in chosing what goes above and below the mux layer.  If you starting thinking about interactions with security and other services, you quickly start thinking about multiple substacks and how to create them, choose among them, etc.

Received on Tuesday, 9 February 1999 15:50:15 UTC