Re: [re] Re: Channels in OHP

From: Peter J. Nuernberg (pnuern)
Date: Mon 09 Jun 1997 - 13:59:07 CDT



Thanks for your reply, Sigi.

> ... 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.
> ...
> 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
> ...

Actually, I'd match "SubProcessId" with thread ID. I still think the serial should be separate from these two issues. We have processes in HOSS that have single threads that issue several overlapping requests, and thus need the serial to keep things straight. For example, if a drawing program stores each graphic object separately, and wants to issue requests to get the contents and attributes of each object, it can just fire off all the retrieval requests through to the back-end, and then assemble the replies correctly using the serial. These two issues are to me also logically separate. The thread ID is part of an identifier of the entity sending/receiving the request/reply. Serials are just opaque fields (i.e., not to be used by the ipc subsystem for identification of entities) that entities can use for whatever ends they choose (e.g., synchronization, ordering, etc.)

I think part of this may be how many objects we expect one ipc entity to manage. If you allow several object per entity, I think you clearly need a serial in addition to the entity identifier. In HOSS, we need two numbers and a host ID to identify an entity, since we need to distinguish threads within processes.

> 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).
> ...
> 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 ...

This is a difficulty, and it's not clear to me how to get around this. Perhaps the reference architecture people would like to comment on this matter...? What I would find useful is a statement of what was agreed upon on the ref arch issue. (If someone would like to send me a few paragraphs, gif images, etc., I'll post them to the OHS www site.) Personally, I don't have any objection to a session ID in the header, but I guess it would be nice to see how this fits in the architecture discussions.

_(fwd link)_In any event, suppose you had the following scenario. An app communicates to a link service through a session manager. Ignoring for a moment the collaboration problems with this (don't hit me, Jörg!), can the session manager be abstracted out of this discussion? It seems to me that the link service can logically address (in the header) it's messages to the app but physically route them to the session manager. (It is presumably just sending this to a port - it should care who owns this. I think there is an analogous argument in the RPC world, right Chimera folks?) The app can logically address the link service in the header and ignore the session manager for the same reasons, I believe. So, although I don't in principle object to the session ID in the header, I'm not sure why it needs to be there. You pointed out that the session ID can be used to identify uniquely the applicable session manager, but I'm not sure why you need to ever identify this entity. (Logically, I mean. Physically, of course you do, but that isn't relevant to the header discussion.)

Now, because I'm sure it has been difficult for Jörg to not flame me this long :-) I'll bring up collaboration again. We should decide a couple of things:

    _(fwd link)_
  1. Do we want to handle collaboration in version 1?
  2. If so, what to we need to add to the header?

What do folks think about these questions?

-Pete



This archive was generated by hypermail 2.1.5 : Tue 13 Aug 2002 - 07:20:41 CDT