Hi,
1. Overview
>
> * The overview mentions "PV locking" but nothing further is said. Is
> this an omission?
>
Hmmm... right, nothing to do with the protocol spec.
(However, the API is designed to allow efficient locking).
>
> > In practice, this means there is no need for a pvAccess equivalent of
> > Channel Access' EPICS_CA_MAX_ARRAY_BYTES.
>
> * The existence of EPICS_CA_MAX_ARRAY_BYTES is an implementation detail
> and not required by the CA protocol.
>
The sentence was added to make things more understandable. That's why it's
in italics.
>
> 2. Data Encoding
>
> > This MUST be done by inserting just enough bytes before the first
> > element of the array.
>
> * So padding is inserted between the array size and the first value?
>
Yes.
> Perhaps an example is in order?
>
Planned (see Missing aspects section - last item).
> Each message contains an endiannes flag
>
> * Can a endpoint change endianness mid way through a TCP session?
>
In case where server is an gateway (pass-thru type), yes. This must be
indicated at connection time, see 15.3.
* Given the small message size, are there measurable performance
> benefits to allowing the sender use different endianness for UDP?
>
Data over UDP + segmented messages (images over multicast).
2.1 Sizes
>
> * How should an endpoint react if it decodes a negative size?
>
TCP disconnect where encoding is wrong, definitely for sizes (you get lost
in the stream then).
Note that this will change to support negative offsets (== offset from end
of the array).
>
> 2.2 User Data
>
> * The sub-sub-sections in this document should be numbered.
>
>
> 2.2 User Data (Status)
>
> * What are the rules for decoding the status? What about type < -1 or > 3?
>
> (The optimization for StatusOK saves only 2 bytes. Is this worth the
> extra complexity in decoding?)
>
This question already came up in the past.
OK is sent pretty often. To avoid object recreation, special code -1 means
"reuse static object"
against comparing 3 fields to zero.
Not a big overhead, but we decided in this case, it's worth special code.
> 2.2 User Data (Introspection Data)
>
> * I find the description of the encoding, particularly for structure and
> structureArray, to be unclear. Perhaps this would be better to use a
> different syntax like:
>
> COUNT = [0-254] | (255 + [0x000000ff-0x7fffffff])
>
> BYTE = [0-255]
>
> STRING = COUNT , {BYTE}
>
> ID = [0-65535]
> NULL_TYPE = 0xff
> ONLY_ID = 0xFE , ID
> FULL_ID = 0xFE , ID , FieldDesc
>
> SCALAR_ID = ID
> SCALARARRAY_ID = ID
> STRUCT_ID = ID , COUNT , {STRING + FieldDesc}
> STRUCTARRAY_ID = ID , FieldDesc
>
> PLAIN_TYPE = SCALER_ID | SCALARARRAY_ID | STRUCT_ID | STRUCTARRAY_ID
>
> FieldDesc = NULL_TYPE | ONLY_ID | FULL_ID | PLAIN_TYPE
>
We need both.
> 3. Connection Management
>
> > Echo message MUST be periodically sent until response is received or
> > the connection is reported to be lost.
>
> * Who is reporting the connection as lost? Is this meant to depend on
> the TCP implementation? Would it be better to fully specify the timeout
> delay and response action (close connection) in this document?
>
>
>
> 4. Channel Life-cycle
>
> > If a connection has been already established by the client, it MUST be
> > reused.
>
> * So a client is not permitted to implement any kind of load
> balancing/prioritization? Perhaps replace MUST with SHOULD. Also, how
> could MUST be enforced in this case?
>
See last paragraph of 14.2.
"Each Quality of Service (QoS) parameter value REQUIRES a separate TCP/IP
connection."
> 6. Flow Control
Maybe flow control is not a good naming here...
The "flow control" I am describing here is to make monitor update rates
more fluid under congestion, e.g. instead of getting 10 samples every 10
seconds, getting one every second is much more better idea.
... and (big) buffers cause this problem.
TCP flow control is perfectly fine (no need to re-implement it again). Just
might need some tuning on higher level.
Now having this in mind the flow control sections might become more
reasonable.
> 7. Channel Discovery
> * Will name lookup over TCP be supported?
Yes.
> 9. Protocol Messages
> * What are the rules governing use of segmented messages? (eg. The
> complete application header must be placed in the first segment)
Payload is segmented.
> * Aside from the flow control mechanism discussed above, is there any
> reason to prefer segmented messages to a variable length payloadSize
field?
This leads to variable header size.
And you cannot send a other message over same TCP connection when large
payload is in process of sending.
> Messages MUST BE aligned on a 64-bit boundary.
> Alignment offset MUST be preserved between segmented messages
* Would it be better just to require that segments sizes must be a
multiple of 8 bytes?
Not always true. You can send 15 bytes of payload in one segmented message,
not to split the next e.g. 4-byte integer in the next segmented message.
This makes implementation simpler.
This calls for an example in the spec :)
> 10.5 Search request and 10.6 search response
> * How should searchSequenceID be chosen?
0, 1, 2, 3 .... 0xFFFE, 0xFFFF, 0, 1, 2 ...
> * Should UDP servers honor the replyRequired field?
Yes, but it should be used carefully.
> X. General comments
> It would be a good idea to specify how a client/server should respond to
> unknown messages. If this isn't specified and clients do bad things
> (event printing warnings) this will prevent new messages from being
> introduced in future revisions.
Right.
One would say: if remote side protocol version is greater than local and
unknown message is received, than client can ignore it gracefully. However,
this calls for problems - remote side will never get a response back and so
on...
The spec say that any new version must be backward compatible. Meaning that
remote implementation needs to handle it - or throw unsupported exception
to an user or transform request to what older version understands.
ps I hope I was not too short with answers (being busy)...
Matej
|