2002 2003 2004 <2005> 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 | Index | 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: primitive data types, was: ICE and TIPC |
From: | Ralph Lange <[email protected]> |
To: | EPICS Core Talk <[email protected]> |
Cc: | Kay-Uwe Kasemir <[email protected]> |
Date: | Sat, 30 Jul 2005 00:44:15 +0200 |
Kay-Uwe Kasemir wrote:
The gateway, on the other hand, needs to understand the data, so that it can send updates to different clients using different deadbands. This mean we have to nail the basic types down. Or would the gateway only fan data out to multiple clients if they use the same subscription request (filter, events), so that the gateway can treat the data as an octet array?
My guess is that if the Gateway would keep a separate copy of the data for each different subscription request, it would end up being quite useless - or: much less useful. It would have to keep multiple copies of the same data just because clients wanted a slightly different filter (e.g max update rate). Not efficient. It would completely lose its functionality to shield the IOC from misbehaving clients: If e.g. a single client would subscribe to the same channel many times with a slightly changed max-update-rate, every single connection would lead to another subscription down to the IOC. Using that knowledge you could write a ten-liner that kills an IOC through a Gateway. Not good.
The Gateway needs to understand the data. We have to nail the basic types down.I would prefer the type info thing to be a struct (type, bitwidth, ...) rather than a large enum.
I would rather not call these types "network" types because they are mandatory for DataAccess even if there is no network involved. The network must support them, too - sure. Just as every other app or layer that uses DataAccess.
Ralph