eCAL 6 Ideas

[FlorianReimold]

This is an ugly list of Ideas for eCAL 6. So Ideas, that we would like to have, but that may not be feasible with eCAL 5.

This list was taken over from another issue tracker.

---

• Make eCAL RAII (-> have an eCAL Object)
  • Singleton interface can be added after the fact by having a global eCAL Object
  • Should improve testing in a single Process, as multiple eCAL Nodes can be spawned
• Support Shared-memory across different hosts (-> for Docker!)
• Make publishers offer different layers (e.g. UDP and TCP) and let the subscriber decide. Currently the publisher must decide which layer must be used
• Introduce a kind of domain concept to allow running multiple isolated ecal setups on the same host 

API related changes:

• Client Server should also support encoding for client / server requests (we don't have that yet, but in theory, also capnproto service requests / responses could be supported).

• Remove eCAL Logging API and create spdlog sink instead: #1377

Local Communication:

• Clocklock mutex as default

[rhd]

eCAL can't get any traction where I work because of the DNS requirement.

I'd like to propose we somehow work around the DNS requirement? Some possibilities:

1) Allow the user to specify a node name and ecal can keep track of the node name to ip mapping during the initial multicast handshake 2) Fake it out. Use the IP address as a fake hostname. If eCAL sees a hostname of 1.2.3.4, it knows to use that IP address instead of doing a DNS lookup. 3) Do away with DNS all together and simply use IP addresses for everything.

Forcing either 1) running a DNS server or 2) managing hosts file across all nodes to use eCAL is really painful on embedded systems.

With that said - I'm sure there are 100 things that make this not so easy.

Thanks!

[FlorianReimold]

@rhd: Thanks for that feedback! DNS is only needed for TCP based communication, which is the Client-Server Service Protocol as well as the TCP Publish Subscribe Protocol. For the normal eCAL Communication (Pub-Sub via Shared Memory and UDP) you don't need any DNS. I guess you would need the Client-Server Protocol to work without Hostname Resolution?

I would be very interested in your use-case, as well as the libraries that you are using instead (only if you are allowed to share those kind of information, of course)

Forcing either 1) running a DNS server or 2) managing hosts file across all nodes to use eCAL is really painful on embedded systems.

I totally agree with that

[rhd]

Hi @FlorianReimold - thanks for the clarification! I actually thought DNS was needed for everything (except local). Good to know it's not true.

Just to make sure I understand, if you have two nodes with the same hostname but different IPs, eCAL pub/sub will still work across the network?

If we remove eCAL from the equation, it's safe to say that DNS is not a requirement for TCP to work. I'd love to see the same capability passed onto eCAL TCP comms :)

Anyway, thanks again - eCAL seems like a great product and I'm happy to see the continued development and discussion about the future.

[FlorianReimold]

if you have two nodes with the same hostname but different IPs, eCAL pub/sub will still work across the network?

Yes, that is the case. eCAL will use UDP Multicast in that case and not address any other host directly, so no IP address of the other host is needed. You only need to make sure that the multicast packages reach the correct network interface by setting a route, but when you only have 1 interface, you may even be able to skip that step.

You can check the guide in our documentation on how to do that on Windows and Linux: https://eclipse-ecal.github.io/ecal/getting_started/cloud.htm

As most embedded systems run either Linux or at least some POSIX (-like) OS, you should be able to translate the Linux way of doing things to most embedded operating systems as well.

If we remove eCAL from the equation, it's safe to say that DNS is not a requirement for TCP to work. I'd love to see the same capability passed onto eCAL TCP comms :)

That is correct. The reason why we do need DNS for TCP is that TCP creates 1:1 connections and doesn't have a multicast protocol. Therefore, you always need an address of the other host, which can either be the IP address or a hostname which has to be resolved to an IP via DNS.

We assume that each host has 1 (and only 1!) hostname, so this is perfect for "addressing" a host via UDP Multicast, where we actually don't need a proper address. If we would have used an IP address, we would have stood in front of the problem that each host can have many IP addresses and there isn't really a way to automatically choose the correct one. The same goes for the TCP Layer. If eCAL shall address the other host via IP address directly (so we don't need DNS), we will probably have to rely on some user configuration. It is absolutely doable, but we just chose to leave the user configuration in /etc/hosts and rely on hostname resolution through that.

Anyway, thanks again - eCAL seems like a great product and I'm happy to see the continued development and discussion about the future.

Thank you 😊