From: Jim Whitehead (ejw_at_ics.uci.edu)
Date: Mon 09 Jun 1997 - 16:43:55 CDT
>I have had some trouble with this as people keep telling me that routing
>information should not be in the protocol. However I find that this
>information *does* need to be present,since the linkservice and the session
>manager actually have to look at this information at times.
Right, but the question is where should the routing information be present? What I would like is a protocol where each OHP client has a virtual connection to an OHP server. The messages passed back and forth don't have any routing information, because the model is that each client has its own dedicated connection to the server. If a particular transport protocol decides to multiplex several of these connections together, that is the choice of the particular implementation. In this case, the implementation could decide to add routing information to the original packet. However, this information does not have to ever have to be seen by the client.
>1. HostId (typically IP address)
>2. SessionManagerId (typically the Port the session manager is listening on.
>The session manager is what used to be called the client side shim or
>Runtime or tool integrator, and there is one per machine per user)
>3. ApplicationId (typically the name of application)
>4. SubProcessId (because some applications may manage more than one doc)
I think this hints at the underlying difficulty. In an OHP system, there are only two classes of processes: an OHP client, and an OHP server. As far as the OHP is concerned, there is no such thing as a Session Manager. The need for a Channel identifier derives from having a Session Manager, a single point of connection between the OHP server and many OHP clients. Thus, when something like a Channel identifier shows up, it looks odd because it isn't strictly needed if every client has its own personal connection to an OHP server.
What might help is to have a clear separation between the messages being passed (the application level) and the mechanism by which they are passed (the transport level). Based on the current OHP draft, it appears there is a need for a generic multiplexing high-level transport protocol. A possible protocol stack for this is:
OHP (Application Level)
Generic Multiplexing Protocol
(RPC,HOSS IPC -- could omit this layer perhaps)
TCP/IP Channel information belongs in the Generic Multiplexing Protocol level, not in the Application Level.
This archive was generated by hypermail 2.1.5 : Tue 13 Aug 2002 - 07:20:43 CDT