EPICS V4 Protocol Proposal - PowerPoint PPT Presentation

Loading...

PPT – EPICS V4 Protocol Proposal PowerPoint presentation | free to download - id: 16ed1b-MWI5Y



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

EPICS V4 Protocol Proposal

Description:

On the EPICS wiki, but wasn't widely viewed ... Types defined by an ASCII protocol and or GUIs. Instances loaded via ASCII protocol and or GUIs ... – PowerPoint PPT presentation

Number of Views:75
Avg rating:3.0/5.0
Slides: 38
Provided by: jeffre147
Learn more at: http://isacwserv.triumf.ca
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: EPICS V4 Protocol Proposal


1
EPICS V4 Protocol Proposal
  • Jeff Hill

2
Summary
  • Background
  • Motivation
  • Requirements
  • Some Choices
  • Data Types
  • Protocol
  • Next steps

3
Background
  • An HTML document describing the proposed protocol
    has existed for some time
  • On the EPICS wiki, but wasn't widely viewed
  • With this talk I am hoping for a wider audience,
    and some additional opportunity to receive
    feedback

4
Motivation Runtime Defined Types
  • Implement put, get, and subscribe for runtime
    defined types (RDTs)
  • Programming language design time defined - data
    structures
  • Fixed during Client side tools design and
    development
  • Configuration - run time defined - data types
  • Types defined by an ASCII protocol and or GUIs
  • Instances loaded via ASCII protocol and or GUIs

5
Motivation Runtime Defined Types
  • Loose coupling between runtime defined types of
    client side tools and services
  • Service type can be superset of the clients type
  • Requires runtime introspection of types
  • The flexibility to develop project, site, and
    discipline specific extensions
  • Interoperating with general purpose components
  • w/o delays waiting for a new release of core
    software
  • Loose coupling doesnt mean un-typed

6
Motivation Recursive Services
ServerServer
Server
Record
Device Support
7
Motivation Recursive Services, Examples
  • Put Request
  • Gateway
  • value lt rightAscension, declination gt
    time-stamp,
  • request-modifiers db process-passive ,
    synch-event-id
  • Server
  • value lt rightAscension, declination gt
    time-stamp,
  • request-modifiers db process-passive ,
    synch-event-id
  • Record
  • value lt rightAscension, declination gt
    time-stamp,
  • request-modifiers lt db process-passive ,
    synch-event-id
  • Device Support
  • value lt rightAscension, declination gt
    time-stamp,
  • request-modifiers synch-event-id

8
Motivation Recursive Services, Examples
  • Subscribe Request
  • Gateway subscribe request
  • request-modifiers event-spec, max-rate,
    dead-band, filter-expression
  • Server subscribe request
  • request-modifiers event-spec, max-rate,
    dead-band, filter-expression
  • Record subscribe request
  • request-modifiers event-spec, max-rate,
    dead-band, filter-expression
  • Device Support subscribe Request
  • request-modifiers event-spec, max-rate,
    dead-band, filter-expression
  • Each layer has multiple clients, single entity
    below
  • Generalize N subscription request modifiers in
    scope
  • To a less specific superset subscription request
    modifier
  • Install new, timely removal of preexisting,
    subscription

9
Motivation Recursive Services, Examples
  • Subscribe Response
  • Device support subscription update
  • value time-stamp, LANSCE beam-gate-state
    gt
  • Record support subscription update
  • value time-stamp, alarm-status,
  • LANSCE beam-gate-state gt
  • Need both situations
  • Generic clients work despite presence of LANSCE
    beam-gate-state
  • LANSCE specific clients benefit from presence of
    beam-gate-state

10
Requirements Backward Compatibility
  • All functionality available with legacy protocol
    available in new protocol
  • Both legacy and new protocol engines co-resident
    during, indefinite length, transition period
  • At large sites a staged transition must be
    possible
  • At some sites it might be optimistic to assume
    that a transition will ever occur

11
Requirements Runtime Defined Types
  • RDTs a set of properties on the wire
  • Their names
  • Their transport order (can be hierarchical)
  • Their transport primitive types
  • Topology learned from snap-ins at runtime
  • From the client side tool
  • From service snap-in

12
Requirements - Efficiency
  • Asynchronous request response behavior
  • i.e. multiple simultaneous requests
  • Binary (not string) transport of binary values
  • Description of User defined types
  • Can be communicated just once, and does not
    accompany every instance of the data

13
Requirements - Obvious
  • Twos complement signed integers
  • IEEE floating point
  • Support for types used by 64 bit CPUs
  • Will need disciplined conversion when larger
    types are converted to smaller ones
  • Data Access library takes care of this
  • And, or software emulation on 32bit systems

14
Some Choices
  • Data elements are not naturally aligned
  • Allows for more compact protocol
  • Natural alignment doesnt help that much
  • When host, network octet order dont match
  • When TCP hands off data on any octet boundary
  • Can cause double copying to occur
  • Network byte order for multi-octet primitive
    types
  • Somewhat arbitrary choice we currently use
    big-endian

15
Some Choices
  • Implemented as Services
  • Channel name resolution
  • Authentication
  • Server diagnostics
  • Benefits
  • Well defined boundaries allow
  • Multiple implementations and authors
  • Site, project, culturally specific implementations

16
Data Types Public
17
Data Types Protocol Private
18
Data Types UINTN, 1 or 2 Octets
19
Data Types UINTN, N Octets
20
Data Types String, UTF-8
21
Data Types Dimension Sequence Definition,
Dimension Bound Definition
22
Data Types Property Transport Sequence
Definition
23
Property Transport Sequence
  • Packed binary
  • Not naturally aligned
  • As specified, PTSD

24
Protocol Summary
  • Initiate
  • Define, expunge channel
  • Swap channel Ids
  • Define, Expunge Property Id
  • Swap Property Ids
  • Define, Expunge Property Transport Sequence
  • Swap property transport sequence definition id
  • IO Requests
  • Write, unacknowledged
  • Write, acknowledged
  • Read
  • Subscribe
  • Invoke
  • Command / response
  • Cancel
  • Server verify

25
Protocol Initiate

26
Protocol Define, Expunge Channel
27
Protocol Swap Channel Identifiers
28
Protocol Define Property
Channel name, optionally includes property
hierarchy path
29
Protocol Swap Property Identifiers
30
Protocol Define, Expunge Property Transport
Sequence
31
Protocol - Swap Property Transport Sequence
Identifiers Request
32
Protocol Write, Unacknowledged
33
Protocol Write, Acknowledged
34
Protocol - Channel Read or Subscribe
35
Protocol Generic Invoke
36
Protocol Server Verify
37
Next Steps
  • Perhaps we form a working group
  • Finalize list of our unique motivations,
    requirements
  • Design / review protocol definition
  • Write protocol libraries we have the expertise
About PowerShow.com