iceoryx apps may not run on all platforms

[elfenpiff]

Brief feature description

The current idea of iceoryx is that we fully support Linux and QNX. Windows, MacOS and FreeBSD are handled as developer platforms, this means one can develop, compile and run iceoryx applications with a restricted functionality. So you can always establish a full communication on every platform but on some without certain safety or security insurances or tweaks like cpu affinity or priority.

But those platforms have different restrictions on certain system resources. For instance on Windows a path name cannot be longer than 255 characters, in linux it can have 1023 characters. The underlying mechanism of iceoryx now may restrict the top level API on each platform differently, for once because we create a file lock or socket with the same name as the runtime name.

With that it is possible to have a runtime name in linux with at most 250 characters (the 5 remaining characters are used for the .lock suffix) - but not on Windows - since the whole path cannot be longer than 255 characters. In both platforms we store the sockets, lock files in directories, linux can handle this but in windows the file name length of the lock file is restricted by the identical maximum path length.

This issue restricts our iceoryx applications too much to a certain platforms when a simple thing like a slightly longer runtime name makes an application incompatible with windows for instance. To not support all features on every platform allows the developer still to run all applications and establish communication (without security/safety insurance) but those implicit platform resource restriction which directly influences the public API defeat the purpose of developer platforms.

Detailed information

We have multiple ways of mitigating this.

• Every platform has the same upper limits for resources. For instance same IOX_UDS_SOCKET_MAX_MESSAGE_SIZE, IOX_MAX_PATH_LENGTH etc. Then we would be unable to use the full potential of some platforms but it can be implemented quickly.
• We have to handle this in the abstractions in iceoryx posh. This can take a lot of time but would be the most sustainable approach. For instance instead of naming the file locks and sockets like the runtime name we generate id's of a certain length which are supported on every platform.
• We could also handle this in the hoofs abstractions but then we again do not use the full potential of the underlying platform and we restrict also our wrappers. Sometimes the user wants to run only on linux therefore I suggest to handle it only in posh. The hoofs should always provide the full potential of the underlying platform.

[elfenpiff]

cc @mossmaurice @dkroenke @budrus @elBoberido

Do you have any thoughts on that?

[elBoberido]

@elfenpiff is the last sentence of the third option meant to be on its own?

I also don't think that option one is the worst and also not feasible. What if we add a new platform which has more restrictions, then we need to break all the other applications even if they never intend to run on this platform. Option two would be the best but I do not really understand what option three means.

In general I don't think this is a big problem. Usually the user would get a compile time error. Sometimes maybe a runtime error but I think it is out of scope for the near term that one can just run every application on each platform without restricting all user to the lowest common dominator.