Experimental Physics and
Industrial Control System

Ralph Lange <[email protected]> · Tue, 26 Jul 2005 16:51:11 +0200

Well, yes. Sure. But: wasn't that the point?!

Maybe I'm misunderstanding the discussion, but for me the line of

argumentation is as follows:

- There will be buffer boundary issues when transferring strings (or

structs or arrays). If one of these things is larger than a buffer - for

sure. Else - only now and then when filling these things into a network

buffer hits the buffer end.

- The user interfaces (APIs) to those things should completely hide

these issues.

- Therefore the implementations of these APIs must be able to cope with

buffer boundary issues, i.e. they must be able to handle storage in

non-contiguous blocks. The interface must allow for such implementations.

If we're trying to agree on one interface, that interface must allow

non-contig.-storage implementations, else CA won't be able to use it.

If we're trying to agree on one implementation that is reusable all over

the place, that implementation must be able to handle non-contiguous

storage, else CA won't be able to use it.

It is desireable to separate the interface from the implementation, as

this would allow other implementations (that might be

smaller/simpler/faster by not supporting non-contig.-storage) to be used

in adequate places while still keeping the same interface.

If we allow something in the interface that requires contiguous storage

(such as c_str), we either restrict the implementation to contiguous

storage (which won't work for network buffers) or force the

implementation to double-buffer everything to have it in a contiguous

place (which is bad in performance and memory fragmentation issues).

Or do I miss something important here?!

Ralph

Kay-Uwe Kasemir wrote:

On Jul 26, 2005, at 05:49, Ralph Lange wrote:

1. Learning the native type of data is part of the DA interface. The

DA interface is purely about data and does not have any notion of

network transport. An application may access things within a library

or through shared memory using DA without any network involved.

I agree, and if you do,
doesn't it follows that the application
shouldn't have to deal with
possible network buffer boundaries?
The application should see a data interface
that allows random access:
List the properties,
learn that the 5th property is the "value",
typed as some sort of number, then fetch it as a double.
Ask for the "units" property as a string, ...

The V3 channel access library does hide the network
delays and buffer boundaries from me,
I eventually get the full DBR_CTRL_XXX
and can access any piece in there in random order.
(Yes, it requires pre-configuration of the max. array size)

Why should the new data access interface
involve the application in the handling of the
incoming network stream byte-by-byte,
maybe first receiving the time stamp,
then a few initial characters of a string value,
then the next 2 chars, ...?

Thanks,
-Kay

--
Ralph Lange               [email protected]     Tel: +49 30 6392-2117
BESSY Controls Group      www.bessy.de             Fax:      ...   -4859

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System