The assertion triggers when a custom type does wasn't listed in a type ID block like this: https://github.com/actor-framework/actor-framework/blob/master/examples/custom_type/custom_types_1.cpp#L15
-- Building for: Visual Studio 16 2019
-- Selecting Windows SDK version 10.0.18362.0 to target Windows 10.0.17763.
-- The CXX compiler identification is MSVC 19.28.29335.0
Yeah, C2059 indicates that your version of MSVC does not recognize the new syntax: https://docs.microsoft.com/en-us/cpp/error-messages/compiler-errors-1/compiler-error-c2059?view=msvc-160
😂
🤔
Hello guys. I'm building caf for Android and got this kind of error.
/home/alexey/.conan/data/caf/0.17.4/mypos.restart+fiscal-core/stable/build/bf600042e8b36bba73e1be4b180544c3b48c09a1/source_subfolder/libcaf_io/src/io/network/default_multiplexer.cpp:803:13: error: no matching function for call to 'getsockname'
getsockname(fd, reinterpret_cast<sockaddr*>(&sa), &len));
^~~~~~~~~~~
/home/alexey/.conan/data/caf/0.17.4/mypos.restart+fiscal-core/stable/build/bf600042e8b36bba73e1be4b180544c3b48c09a1/source_subfolder/libcaf_io/caf/detail/call_cfun.hpp:53:14: note: expanded from macro 'CALL_CFUN'
auto var = expr; \
^~~~
/opt/android-ndk-r21e/toolchains/llvm/prebuilt/linux-x86_64/bin/../sysroot/usr/include/sys/socket.h:310:18: note: candidate function not viable: no known conversion from 'caf::io::network::socket_size_type *' (aka 'unsigned int *') to 'socklen_t *' (aka 'int *') for 3rd argument
__socketcall int getsockname(int __fd, struct sockaddr* __addr, socklen_t* __addr_length);Can I overcome this somehow?
These types are defined here: https://github.com/actor-framework/actor-framework/blob/master/libcaf_io/caf/io/network/native_socket.hpp#L16.
Try change
using socket_size_type = unsigned; to ... = int; for Android.
But you may want to avoid functions like
publish and remote_actor on Android anyway. Giving devices that aren't under your control full access to remote CAF nodes via CAF's internal protocol raises several security concerns.
Just mentioning it. If you're using the I/O module for broker and custom protocols it's fine.
auto timer_handle = create_timer(duration, target, args....);
timer_handle.cancel()
or self
it could be a closure with an actor too, thinking of it
Actually making a lambda would make for an easier programming task as I think through it
Hm, I had the idea of a
run_delayed feature a while back: https://github.com/actor-framework/actor-framework/issues/584#issuecomment-608627958. If that function would return a disposable/cancellable, would that be what you're looking for?
what is the recommended way to handle a broker attempting a reconnection on failure? I tried having it emit a delayed message to a supervisor on error. The supervisor attempts to use spawn_client, but keeps failing with an error code 17. It it's the direct time the connection is attempted it will pass though.
17 is cannot_connect_to_node: https://github.com/actor-framework/actor-framework/blob/master/libcaf_core/caf/sec.hpp#L61. If you call to_string on the error, it should also print additional information.
In general, instead of doing error signaling manually, I'd recommend just terminating the broker with an error and monitor it from the supervisor. Whenever it sees the broker go down, you can start some reconnect logic (e.g. try reconnect every X seconds up to Y times).
Are you doing the file I/O per actor or do you have one actor dedicated to file I/O? In the latter case, I'd recommend detaching this actor since it's probably blocked on some file handle most of the time. If you have a large volume of log events, you may also want to add some token-based mechanism to make sure the other actors slow down if the file I/O can't keep up.
Also sounds like a good use case for the new flow API, so when it lands that could make your life a bit easier.
Hi there. I would like to use CAF for a distributed application consisting of server nodes which hold different actors. Clients can connect to the server cluster via their own client actor. I did some tests and this kind of architecture seems to be possible to implement in CAF.
There are two problems though, both related to security and the fact that one is not able to trust clients. First, it is important, that client actors are only allowed to send messages to specific actors on the server cluster, so clients can not mess with server operation. Then, it should not be possible for the client to spawn a server internal actor.
I guess both problems have to be handled in the middleman on the server, where messages can be filtered based on the location of the sender (all server actors are in the same network). My question is if these security measures are already possible in CAF and if not, how difficult would it be to implement them?
There are two problems though, both related to security and the fact that one is not able to trust clients. First, it is important, that client actors are only allowed to send messages to specific actors on the server cluster, so clients can not mess with server operation. Then, it should not be possible for the client to spawn a server internal actor.
I guess both problems have to be handled in the middleman on the server, where messages can be filtered based on the location of the sender (all server actors are in the same network). My question is if these security measures are already possible in CAF and if not, how difficult would it be to implement them?
When talking to untrusted clients, I wouldn't connect them at the CAF level and use a different protocol instead. We have started
caf_net in the incubator to help with this kind of scenario. So far there is an implementation for WebSocket available (examples see here: https://github.com/actor-framework/incubator/tree/master/examples/net) and some utilities for interfacing actors with network protocols (actor shell).
These APIs are still rather low-level at the moment, but that's the route I would go down.