1 / 37

EPICS V4 Protocol Proposal

EPICS V4 Protocol Proposal. Jeff Hill. Background Motivation Requirements Some Choices Data Types Protocol Next steps. Summary. An HTML document describing the proposed protocol has existed for some time On the EPICS wiki, but wasn't widely viewed

shayna
Download Presentation

EPICS V4 Protocol Proposal

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. EPICS V4 Protocol Proposal Jeff Hill

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

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

  4. Implement put, get, and subscribe for runtime defined types (RDTs) • Programming language – design time defined - data structures • Fixed during Client side tool’s 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 Motivation – Runtime Defined Types

  5. 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 doesn’t mean un-typed Motivation – Runtime Defined Types

  6. ServerServer Server Record Device Support Request RDT Request RDT Response RDT Response RDT Request RDT Response RDT Motivation – Recursive Services

  7. Put Request • Gateway {value < rightAscension, declination > { time-stamp}, request-modifiers { db { process-passive } , synch-event-id } } • Server {value < rightAscension, declination > { time-stamp}, request-modifiers { db { process-passive } , synch-event-id } } • Record { value < rightAscension, declination > { time-stamp}, request-modifiers <db { process-passive } , synch-event-id} } • Device Support { value < rightAscension, declination > { time-stamp}, request-modifiers {synch-event-id } } Motivation – Recursive Services, Examples

  8. 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 Motivation – Recursive Services, Examples

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

  10. 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 Requirements – Backward Compatibility

  11. 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 Requirements – Runtime Defined Types

  12. 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 Requirements - Efficiency

  13. Two’s 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 Requirements - Obvious

  14. Data elements are not naturally aligned • Allows for more compact protocol • Natural alignment doesn’t help that much • When host, network octet order don’t 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 Some Choices

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

  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. Packed binary • Not naturally aligned • As specified, PTSD Property Transport Sequence

  24. 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 Protocol – Summary

  25. Protocol – Initiate

  26. Protocol – Define, Expunge Channel

  27. Protocol – Swap Channel Identifiers

  28. Channel name, optionally includes property hierarchy path Protocol – Define Property

  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. Perhaps we form a working group • Finalize list of our unique motivations, requirements • Design / review protocol definition • Write protocol libraries – we have the expertise Next Steps

More Related