Experimenting with CAF -- a few observations and questions [ 0.17.6 ]

[Bashuman Deb]

Hi,

I am trying to develop a concurrent networking application on CAF. It is fun :) So here are some issues I faced as a newbie and as a result a few redundant questions

1.  Is there any documentation around how the infer_handle_from_fun mapping works? I was looking for instance/reference/pointer handling and a principled way to pass around actor references between actors when spawning stuff.

2. That brings me to the second question. Is there a paradigm to pass around actor references in actual messages ? 

3. Are there any more specific examples on using the network broker for IP communication? As an example, I was trying to extract the sender ip and sender while using a udp_datagram servant and am plodding around the source code to understand if it is encoded somewhere in the new_datagram_msg.

4. Lastly super mundane, lazy question: I for the death of me cannot get this lambda to compile:

caf::others >> [ = ] (caf::message_view & m) -> caf::result<caf::message> {

              return caf::sec::unexpected_message;

          }

This is straight out of the documentation and the compile error message seems to ask for the very signature being supplied. Am I getting  something terribly wrong ?

-Bashuman

[Dominik Charousset]

Hi,

I am trying to develop a concurrent networking application on CAF. It is fun :)

Welcome aboard. :)

So here are some issues I faced as a newbie and as a result a few redundant questions

1.  Is there any documentation around how the infer_handle_from_fun mapping works? I was looking for instance/reference/pointer handling and a principled way to pass around actor references between actors when spawning stuff.

I think you’re headed into the wrong direction with this utility. It only does one thing: check whether we are dealing with a caf::actor or with a caf::typed_actor. It infers this information by looking at the return type (behavior -> actor, typed_behavior -> typed_actor) and/or the self pointer argument, if present.

2. That brings me to the second question. Is there a paradigm to pass around actor references in actual messages ?

I wouldn’t call it ‘paradigm’, but you can simply send the handle around in a message. For example, `self->send(buddy, “hi there from”, self)` would match a hypothetical `[](const std::string& greeting, caf::actor src) {…}` handler at `buddy`. Note that CAF includes sender information with each message to enable request/response-style communication. Shipping actor handles around is not necessary to realize this pattern.

3. Are there any more specific examples on using the network broker for IP communication? As an example, I was trying to extract the sender ip and sender while using a udp_datagram servant and am plodding around the source code to understand if it is encoded somewhere in the new_datagram_msg.

The msg object gives you the datagram_handle. With this, you can query some information like `self->remote_addr(hdl)`. Have a look at the abstract_broker for more details.

4. Lastly super mundane, lazy question: I for the death of me cannot get this lambda to compile:

caf::others >> [ = ] (caf::message_view & m) -> caf::result<caf::message> {

              return caf::sec::unexpected_message;

          }

This is straight out of the documentation and the compile error message seems to ask for the very signature being supplied. Am I getting  something terribly wrong ?

What do you mean by ’not compiling’? Note that `others` only works for blocking actors, ‘regular’ actors use the default handler for this. Our general advise is not use blocking actors (except scoped_actor), because they come with many caveats and pitfalls.

Hope that helps.

    Dominik

[BD]

Thank you ! This was super useful. My code is looking better now.

Another newbie question if I may:

I have datagram servant that binds a UDP port, capable of receiving packets from various hosts. For 0.17.6 the remote_addr method on the broker goes through the underlying servant that uses ::getpeername to get the peer address. This works well for TCP oriented servants but does not work for the use case in question since the UDP socket is not connected. One way of solving the problem would be to ferry the ip_endpoint  that was got in the ::recvfrom in the new_datagram_msg struct itself

Am I looking at it all wrong ? Are there better methods to get the remote addr for bound UDP sockets ? Are there other ways in which I should approach the problem ?  

-Bashuman

[Joseph Noir]

Hi Bashuman,

it sounds like you got the right idea and the implementation is not correct! Version 0.18 already includes the fix: read the address from locally available data [1]. It requires changes to a few more files though.

Since 0.18 will be release soon, I would recommend switching. There are some API changes, but it includes a lot of improvements!

If that is not an option for you, I already implemented the fixes for 0.17, but they are untested. (See the last two commits here [2].)

Cheers
Joseph

[1] https://github.com/actor-framework/actor-framework/blob/master/libcaf_io/src/io/network/datagram_servant_impl.cpp#L75
[2] https://github.com/actor-framework/actor-framework/commits/topic/udp-remote-info

> --
> You received this message because you are subscribed to the Google Groups "actor-framework" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to actor-framewo...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/actor-framework/e88a40f3-1d60-499c-8f29-1f8b5c4ec07bn%40googlegroups.com.