Jump to content
OpenSplice DDS Forum

Hans van 't Hag

Moderators
  • Content count

    370
  • Joined

  • Last visited

About Hans van 't Hag

  • Rank
    Product Manager

Contact Methods

  • Website URL
    http://ist.adlinktech.com/

Profile Information

  • Gender
    Male
  • Location
    Hengelo, The Netherlands
  • Company
    ADLINK Technology

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I guess that setting has indeed no effect on 6.7 .. but that ticket was about a somewhat strange requirement w.r.t. setting-up soap: ".. Currently missing on the build page is the dependency on the stdsoap2.c file which is expected to be found in the include directory of the soap install directory. Building OpenSplice without this file will fail." So perhaps this is why it considers your soap-setup as invalid ?
  2. maybe switching to 6.9 would help, see https://github.com/ADLINK-IST/opensplice/issues/34#issuecomment-344305476
  3. hmm not sure I understand: the history-depth is 'local' for each reader, so any of those can configure an arbitrary depth. If its about TRANSIENT/TRANSIENT_LOCAL data historical-data availability for late-joiners, then its indeed the topic-level durability_service QoS setting for that topic that defines the amount of 'maintained-historical-data' for any late-joiner (of that topic). Yet still, if your reader calles wait_for_historical_data it will still be the case that you'll see 'at most' your local reader's history-depth of historical samples (as the rest will be pushed-out during the 'provisioning-of-that-historical-data')
  4. Hans van 't Hag

    current_count_changed

    I think there's indeed a difference in interpretation (like there is for the liveliness alive_count_change) of the specification. In OpenSplice its the number of changes .. Similarly for the livelinessChangedStatus "alive_count_change" which for OpenSplice is the number of (alive writer) changes whereas for RTI its the difference-in-counter-value
  5. Hans van 't Hag

    Doesn't work on two machines.

    You're using a 8-years old release, so I'd suggest to migrate to 6.9. Anyhow, I see you didn't configure a networkInterfaceAddress (to be configured in the 'General' section of the NetworkService) so you're probably not using the correct interface adapter.
  6. Hans van 't Hag

    Determination of the used network adapter

    I typically use the logical-name so that the same configuration can be exploited on multiple (similarly 'hosted') machines. Not sure which of the 2 options doesn't work when your WLAN adapter is activated, but I can't imagine why any of them wouldn't work (assuming that both adapters have both unique names as well as unique ip-addresses)
  7. Hans van 't Hag

    DDS configuration for multicast-disabled network

    Perhaps there's some ports that are blocked by the VPN .. not sure .. You might want to try using TCP rather than UDP, configuration then looks something like this: <DDSI2Service name="ddsi2"> <General> <NetworkInterfaceAddress>AUTO</NetworkInterfaceAddress> <AllowMulticast>false</AllowMulticast> <EnableMulticastLoopback>true</EnableMulticastLoopback> <CoexistWithNativeNetworking>false</CoexistWithNativeNetworking> </General> <Compatibility> <!-- see the release notes and/or the OpenSplice configurator on DDSI interoperability --> <StandardsConformance>lax</StandardsConformance> <!-- the following one is necessary only for TwinOaks CoreDX DDS compatibility --> <!-- <ExplicitlyPublishQosSetToDefault>true</ExplicitlyPublishQosSetToDefault> --> </Compatibility> <TCP> <Enable>true</Enable> <Port>6002</Port> </TCP> <Discovery> <Peers> <Peer Address="10.5.150.254:6001"/> <Peer Address="10.5.150.254:6002"/> <Peer Address="10.5.150.254:6003"/> </Peers> </Discovery> </DDSI2Service> Note that above there's a setup for 3 applications that run on the same 10.5.150.254 machine, if you'd run each application on a different machine, you could use the same port-number on each machine (so the port-specification in the TCP-section would be always the same e.g. 6001) in which case you could re-use the same configuration for each node.. If that also doesn't work, it might (again) be an issue with ports being blocked, but then at least you have control over which port to use
  8. Hans van 't Hag

    Building a DDS application under CYGWIN

    When you say "I want the same program code as for an application on a Linux-PC", then that sort of implies that the DDS-API is platform-dependent, which it isn't Of course when you're using OS-calls such as sleeps or timers, you can run into platform-dependent code, but the DDS-API shouldn't suffer from that. I remember us using CYGWIN in the (far) past on windows so theoretically it should be possible, but I'm surely not an expert on it. Perhaps with 'program code' you mean the DDS_sources in which case there's indeed some OS-specific sources (the OS-abstraction-layer under C:\Program Files\ADLINK\Vortex_v2\Device\VortexOpenSplice\6.9.181018OSS\HDE\x86_64.win64\src\VortexOpenSplice\src\abstraction\os)...
  9. There's indeed no such 'break' .. and (thus) you'd have to revert to the (source) timestamp of the received samples. It's still not that easy as historical samples might be produced by different (potentially past-)writers that exploit perhaps-not-sufficiently-aligned clocks .. Note however that (also after wait_for_historical_data()), the datareader's history (of each instance) will be ordered, something that should prevent checking each/every sample .. Anyhow, my advice would be not to rely on such a distinction and if time-validity is an issue, model that validity explicitly in your data(-model)
  10. Hans van 't Hag

    DDS configuration for multicast-disabled network

    Hi, When not using multicast, you must define your set of 'peers' as automatic discovery relies on multicast (which you don't have). So your 'ddsi2' section in the configuration should look like this; <DDSI2Service name="ddsi2"> <General> <NetworkInterfaceAddress>AUTO</NetworkInterfaceAddress> <AllowMulticast>false</AllowMulticast> <EnableMulticastLoopback>false</EnableMulticastLoopback> <CoexistWithNativeNetworking>false</CoexistWithNativeNetworking> </General> <Compatibility> <StandardsConformance>lax</StandardsConformance> </Compatibility> <Discovery> <Peers> <Peer Address="name_or_address_of_machine1"/> <Peer Address="name_or_address_of_machine2"/> <Peer Address="name_or_address_of_machine3"/> </Peers> </Discovery> </DDSI2Service> This should at least work when you have 1 application per machine .. need to dig a little deeper in my memory on how to additionally specify port-numbers in those cases where you'd want to run multiple applications 'per machine' .. PS> I checked-around and as it turns out, the above configuration should also work when running multiple (standalone) applications on a single machine, so you should be 'good to-go' exploiting unicast-only after specifying the peer-list (of all your machines in your network) and instructing DDSI to NOT-use multicast.
  11. OK, so you're on windows (as you mention 'release.bat' which is for windows, for linux you have to source !! the release.com file) .. I just verified that for the 6.9.181018OSS version (for win10/VS2015), the examples build ok (using the provide solution-files) .. So what OpenSplice version and platform are you on (and are you using the solution-files) ?
  12. HI, you're confusing history and durability: history using a KEEP_LAST (with depth 'n') history, allows for each instance (i.e. 'key-value') to maintain up to 'n' samples (like a FIFO queue) meaning that when you don't read 'fast enough', oldest samples will be pushed out of the reader's history in favor of newly arriving samples noting that the KEEP_ALL variant (i.c.w. RESOURCE_LIMITS to 'cap' the resource usage) introduced flow-control where you block the writer(s) if you're not reading fast enough so in your case, a KEEP_LAST reader-history setting with a depth of 100 durability for non-volatile data there's 3 variants: TRANSIENT_LOCAL, TRANSIENT and PERSISTENT durability all 3 flavors allow to retain some 'historical data' for late-joining applications how much data is maintained is driven by the topic-level (!!) QoS-policy settings called DURABILITY_SERVICE (with a history-kind, depth and resource-limits) these settings are on 'topic-level' as writers/readers might not even be present whilst preserving non-volatile data I know the specification isn't that clear about this, but at least this is how OpenSplice DDS works the difference between the 3 being: TRANSIENT_LOCAL data is maintained at the publisher/writer side and its lifecycle is coupled to that of the writer (i.e .writer gone, data gone) TRANSIENT data is maintained by a (distributed set) of durability-services (in our community-edition, these are implicit within each application's library) PERSISTENT data is also maintained by durability-services and is (optionally) written to non-volatile storage (i.e. disk) so it outlives system downtime guess you're looking for TRANSIENT_LOCAL which topic-level durability_service QoS-settings of history_kind=KEEP_LAST and history_depth=1 which will provide the last written sample (for each instance) for your late-joining application Hope this helps..
  13. Hans van 't Hag

    Apache Vortex

    No problem, Cyclone DDS is actually called "Eclipse Cyclone DDS" and (as the name suggests) is an Eclipse IOT opensource-project. Some 'resources' around it can be found here: https://projects.eclipse.org/projects/iot.cyclonedds https://github.com/eclipse-cyclonedds/cyclonedds https://accounts.eclipse.org/mailing-list/cyclonedds-dev We're always looking for feedback and/or contributors and there's several options to do so: and with some contribution examples:
  14. Guess you've not sourced the release.com file which sets up the appropriate environment variables.
  15. Hans van 't Hag

    API stability

    The type-descriptor has been stable for many years and I don't see it being changed anytime soon, yet you're right in that its not a documented/standard interface
×