Re: pvAccess Protocol Specification 05-Feb-2012 cont'd

[Benjamin F. <ben...@he...>]

On Wednesday, February 15, 2012, you wrote:
> I've updated the document with your comments/corrections.

Thanks.

I reply only to those answers that don't satisfy me. Quotations slightly re-
ordered.

> > 4th paragraph: "When connection is closed all related resources MUST be
> > freed".
> >
> > What does "all related resources" mean, exactly? Why demand this?
>
> I wanted to say that server should not keep any resources in case
> client is disconnected.

Ok, what I think I really wanted to have is examples what such resources
could be; I can think of things like sockets, channelIDs, requestIDs; but
maybe you thought of other things?

> > "On server side all channels including their requests MUST be
> > destroyed."
> >
> > What does that mean in terms of the protocol? If the connection is
> > closed I cannot send a channel destroy message, so this is all
> > meaningless.
> >
> > "On client side all channels and their requests MUST be put to
> > disconnected state and searching for channels initiated."
> >
> > What does that mean in terms of the protocol?
>
> Destroyed things cannot be reused anymore. Disconnected can.

But this contradicts the sentence I quoted above: "When connection is closed
all related resources MUST be freed". In my understanding "freed" is a
synonym for "destroyed", and "all related resources" includes all channels
created within the connection.

> In terms of protocol this basically means "take care of your IDs" (as
> described later in the text).

Could you be more specific? Which IDs (supposedly channelIDs). How is care
to be taken, by keeping the IDs or by discarding them? In the former case,
not all resources are freed when connection is lost, in the latter case I do
not see what the thing is that can be reused.

> > The relevant information here is the one about IDs, so IMO the whole
> > paragraph can be reduced to:
> >
> > """
> > When a connection is closed for whatever reason and is later
> > re-established, both sides MUST NOT assume the other side remembers
> > any of the related IDs, such as serverChannelID, clientChannelID, and
> > requestID. Instead, all these IDs MUST be newly allocated.
> > """
> >
> > A question remains: are type IDs (see section 2.7 Introspection Data)
> > also invalidated when a connection is closed?
>
> Yes.

> "IDs MUST be valid only within one connection".

It would be nice if things were as easy as that, but unfortunately there are
IDs that (must) exist even before a connection is established, so this
cannot be true. So you probably mean typeID, channelID (client and server),
requestID. Are there more?

> > It seems to me all these requirements assume a certain form of
> > implementation and prescribe how such an implementation should present
> > things to user code. This is not part of the protocol definition and
> > thus should be relegated to an appendix with recommendations for
> > implementors. The protocol definition itself should not be fraught
> > with irrelevant detail.
>
> Sure. I got some comments asking to put a little more description in
> that is not 100% protocol specification.

I am not against including such information, I am only against mixing it
with the protocol specification. This information should be kept separate
from the main text. Relegate them to an appendix "Implementation Hints"; or
create a separate document ("PvAccess Implementation Tutorial", or "Comments
on how to implement PvAccess", whatever).

> I try to do this, however
> this will make the specification less understandable.

I strongly disagree. The less superfluous and distracting detail the spec
contains, the *more* it becomes understandable. At least that's how it is
for me. Note that I am in no way familiar with any of the existing
implementations, nor the API they offer. It certainly is more important that
people who are not familiar with the existing implementations and API find
the spec understandable, than those who are.

> > Furthermore, the text in this section describes a certain
> > implementation and API, not the protocol requirements. On the protocol
> > side, it suffices to distinguish between a channel that exists and one
> > that does not exist. A channel comes into existence as soon as the
> > client receives (resp. the server sends) the channel create response
> > with success status. It ceases to exist whenever its TCP connection
> > terminates, or whenever a channel destroy response with success status
> > is received by the client (resp. sent by the server). A channel is
> > identified by its clientChannelID and serverChannelID. Channel related
> > messages, i.e. those that contain a channelID may only be sent to
> > existing channels. Client and server must both expect unsolicited
> > channel destroy requests/responses at any time.
>
> Right, this implies a certain level of implementation.
> I was explicitly asked to add these sections.

May I humbly ask that requests for change in (and especially additions to)
the protocol spec be made public on this list? So that others who care about
it can comment or argue against?

Cheers
Ben

________________________________

Helmholtz-Zentrum Berlin für Materialien und Energie GmbH

Mitglied der Hermann von Helmholtz-Gemeinschaft Deutscher Forschungszentren e.V.

Aufsichtsrat: Vorsitzender Prof. Dr. Dr. h.c. mult. Joachim Treusch, stv. Vorsitzende Dr. Beatrix Vierkorn-Rudolph
Geschäftsführerin: Prof. Dr. Anke Rita Kaysser-Pyzalla

Sitz Berlin, AG Charlottenburg, 89 HRB 5583

Postadresse:
Hahn-Meitner-Platz 1
D-14109 Berlin

http://www.helmholtz-berlin.de