EPICS V4 Protocol Proposal

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