1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 <2017> 2018 2019 2020 2021 2022 2023 2024 | Index | 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 <2017> 2018 2019 2020 2021 2022 2023 2024 |
<== Date ==> | <== Thread ==> |
---|
Subject: | Re: EPICS communication paradigm |
From: | bob dalesio <[email protected]> |
To: | renato sanhueza <[email protected]> |
Cc: | EPICS tech-talk <[email protected]> |
Date: | Mon, 13 Nov 2017 12:32:35 -0500 |
---------- Forwarded message ----------
From: renato sanhueza <[email protected].cl >
Date: Mon, Nov 13, 2017 at 1:39 PM
Subject: Re: EPICS communication paradigm
To: Ralph Lange <[email protected]>Hi Ralph,
Mi final conclusions make more sense now thanks to you.As you say the EPICS/CA protocol appears to be an original thing and it is also old. We can easily classify it under the Client-Server Paradigm (Channel Access clients and Channel Access servers communicate) which is also an old an "general" paradigm and the base of many others.This is further confirmed by the fact that EPICS V4 claims to provide a new protocol with RPC communication:
- The Remote Procedure Call Paradigm has a lower level of abstraction than the Distributed Object Paradigm. Even tho it is feasible it makes little sense to me that a new version of any middleware will implement a protocol with a lower level of abstraction.
- In the other hand the Remote Procedure Call Paradigm provides a higher level of abstraction than the "raw" Client-Server Paradigm so it makes sense that EPICS V4 implemented RPC.
Thanks for your time. I hope this discussion also contributed with a little theoretical information for the community :)On Mon, Nov 13, 2017 at 12:15 PM, Ralph Lange <[email protected]> wrote:Hi Renato,One reason making it hard to decide which of the common communication paradigms EPICS/CA are based on: EPICS/CA have been designed in the 80s, i.e. years before Distributed Objects (and their communication paradigms) were developed.If you look at currently commonly used protocols, CA shares a number of properties with OPC UA, in that it offers:
- Discovery: work transparently across multiple servers on local PCs and/or networks
- Global address space: all data is found through its unique name
- On-demand: read and write data/information based on access-permissions
- Subscriptions: monitor data/information when values change
Hope this helps,~RalphOn Sun, Nov 12, 2017 at 1:17 AM, renato sanhueza <[email protected]l > wrote:Hiding things is a common feature associated to a high level of abstraction. Thanks again for your time Mark. I will continue reflecting about this topic with the information you gave me.On Sat, Nov 11, 2017 at 8:36 PM, Mark Rivers <[email protected]> wrote:I'm not a computer scientist by any means. But I think it is fair to say that Channel Access operates at a fairly low level of abstraction. It deliberately hides the "object" nature of EPICS records. It only provides access to specific fields in those records. So there is no capability of introspection of the record structure, etc.
There is a new EPICS protocol called pvAccess, commonly known as EPICS V4. It provides a much higher level of abstraction, and is designed with middleware services as one of its target applications. It allows the transmission of arbitrary structured data with full introspection.
Mark
________________________________
From: renato sanhueza <[email protected]l >
Sent: Saturday, November 11, 2017 4:28 PM
To: Mark Rivers
Cc: [email protected]
Subject: Re: EPICS communication paradigm
Hi Mark,
Thanks for your answer. You give a good summary of the whole communication process. I was asking about the communication paradigm as an attempt to determine in which level of abstraction EPICS works.
For example the Message Passing Paradigm is associated with the lowest level of abstraction in distributed inter-process communications. Message Systems Paradigm (aka Message Oriented Middleware) works in a higher level of abstraction than Message Passing, but lower than Distributed Object Paradigm.
EPICS use the Channel Access Protocol to communicate clients and servers, but I couldn't intuitively map this protocol to any of the "common" communication paradigms I know (besides the Distributed Objects Paradigm).
On Sat, Nov 11, 2017 at 6:59 PM, Mark Rivers <[email protected]<mailto:[email protected]>> wrote: From: [email protected]<
Hi Renato,
What you said is basically correct. An EPICS control system typically consists of multiple channel access servers located on multiple computers. There are also multiple channel access clients located on multiple computers. The clients normally locate EPICS process variables (PVs) on the servers using a UDP broadcast with the PV name, and then connect to them with TCP. They can then subscribe to callbacks from the servers whenever the PV changes (publish/subscribe model), and can write new values to the PVs.
I'm not sure if this answers your question?
Mark
________________________________
mailto:[email protected] nl.gov > <[email protected]<mailto:tech-talk-bounces@aps. anl.gov >> on behalf of renato sanhueza <[email protected]l <mailto:renato.sanhueza@alumnos.usm.cl >>
Sent: Saturday, November 11, 2017 1:05 PM
To: [email protected]<mailto:t[email protected] >
Subject: EPICS communication paradigm
Hi, I am learning about EPICS and I think I understand the basic concepts about it but I am still unable to determine in which communication paradigm is EPICS based on.
My best guess is that EPICS implements the Distributed Object Paradigm because Records are object distributed across different Channel Access Servers. Other technologies which implement this paradigm are CORBA and JavaRMI for example.
I would really appreciate if someone can point me in the right direction.
Thanks in advance
--
Renato Sanhueza Ulsen
Ing Civil Informática.
--
Renato Sanhueza Ulsen
Ing Civil Informática.
--Renato Sanhueza Ulsen
Ing Civil Informática.--Renato Sanhueza Ulsen
Ing Civil Informática.--Renato Sanhueza Ulsen
Ing Civil Informática.