From: Sigi REICH (sr_at_ecs.soton.ac.uk)
Date: Mon 09 Jun 1997 - 02:35:06 CDT
thanks for your answer! I think it is a good idea to add the message name _(fwd link)_to the 'header information'. Concerning the 'serial' ID, I guess this overlaps to some degree with what we specified with #4 ('SubProcessId'). We were thinking of an application managing more than one window, so service requests and replies should be distinguishable on that level; this is quite similiar to the use you propose for transasction semantics.
_(fwd link)_I'll try to express what we meant with #2, the SessionManagerId: When working on the protocol we were assuming 'something' as a runtime at the client's side that is independent of the actual application/viewer. This 'something' has previously been called 'Tool Integrator', 'client side runtime', 'runtime virtual machine', ... We (Hugh and I) agreed on calling it SessionManager. As there can be more than one SM per HostId we thought that we would need another field in the header to allow to uniquely identify the SM. (Within the SM we need to identify the application the message is related to, thus an ApplicationId; as an application can have more than one windows/transactions, we also added a SubProcessId).
When I look at the HOSS definition, it seems that you achieve the same by
identifying a host, a process and lastly a thread:
>source process id - machine name, process name, process id, and
> thread id of the sender
Perhaps this part of the protocol can not really be discussed without an agreed understanding of the 'reference architecture' also including a common definition of how exactly the components interact. Yet, we tried to avoid being involved too much in the ref. arch discussion ...
>What do other people think about a standard header? What fields
>should be in the header? Hugh and Sigi proposed:
> _(fwd link)_
>> 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'm not sure why #2 is there, so maybe Hugh and/or Sigi could tell me
>this. I'd advocate at least adding "message name" and "serial", the
>first having an obvious interpretation, and the second being opaque.
>I've found "serial" to be useful in managing async IPC. For example,
>if a client sends two identical requests to a server and does not
>block on the replies, it may get the replies in "backwards" order. In
>HOSS, anyone can assign any serial to any message they send. By
>convention, if a process is sending a reply to a message, it uses the
>serial on the original message as the serial for the reply. This
>allows processes to "match up" replies to original requests.
>I don't believe that this is too much different than the current spec,
>so I'm not advocating any radical redesign. I think, though, that
>there is some benefit to speak in the above terms (or similar ones) as
>opposed to keeping the same information in a "flat" format as the
>current spec dictates.
This archive was generated by hypermail 2.1.5 : Tue 13 Aug 2002 - 07:20:40 CDT