Yarp: [macOS] mcast and udp not working

[iron76]

Several users (@vtikha included) report that mcast is not working on MacOS. Even a simple read and write test works. Here is the output of yarpserver:

__   __ _    ____  ____  
\ \ / // \  |  _ \|  _ \ 
 \ V // _ \ | |_) | |_) |
  | |/ ___ \|  _ <|  __/ 
  |_/_/   \_\_| \_\_|    

Call with --help for information on available options
Using port database: :memory:
Using subscription database: :memory:
IP address: default
Port number: 10000
yarp: Port /iron active at tcp://192.168.36.97:10000

Registering name server with itself:
 * register "/iron" tcp "192.168.36.97" 10000
   + set "/iron" ips "127.0.0.1" "192.168.36.97" "10.255.37.230"
   + set "/iron" process 53373
 * register fallback mcast "224.2.1.1" 10000
   + set fallback ips "127.0.0.1" "192.168.36.97" "10.255.37.230"
   + set fallback process 53373
Name server can be browsed at http://192.168.36.97:10000/

Ok.  Ready!
 * register "/iron/read"
   + set "/iron/read" ips "127.0.0.1" "192.168.36.97" "10.255.37.230"
   + set "/iron/read" process 53374
-> announce "/iron/read"
 * register "/iron/write"
   + set "/iron/write" ips "127.0.0.1" "192.168.36.97" "10.255.37.230"
   + set "/iron/write" process 53375
-> announce "/iron/write"
 * query "/iron/write"
 * query "/iron/read"
 * query "/iron/read"
 * register "..." mcast "..." "..."
 * set "/tmp/port/1" ips "127.0.0.1" "192.168.36.97" "10.255.37.230"
 * set "/tmp/port/1" process 53375
 * bot set "/iron/write" owns "/tmp/port/1"
 * query "/iron/read"

Here is the yarp write output:

yarp write /iron/write
yarp: Port /iron/write active at tcp://192.168.36.97:10003
>>yarp: multicast connection 224.1.1.3 on network interface for 192.168.36.97
yarp: Sending output from /iron/write to /iron/read using mcast
test

Here is what yarp read:

yarp: Port /iron/read active at tcp://192.168.36.97:10002
yarp: multicast connection 224.1.1.3 on network interface for 192.168.36.97
yarp: Receiving input from /iron/write to /iron/read using mcast
yarp: multicast connection 224.1.1.3 on network interface for 192.168.36.97
yarp: multicast connection 224.1.1.3 on network interface for 192.168.36.97
yarp: multicast connection 224.1.1.3 on network interface for 192.168.36.97

[claudiofantacci]

As of now, this "issue" is still present @apaikan @francesco-romano .
I used the quotation marks because, to the best of my knowledge, is something related to the OS (which somehow disable them by default) and not with YARP.

[francesco-romano]

To test the UDP you can do the following stuff:

• Run a yarpserver
• Run a testgrabber: yarpdev --device test_grabber --period 0.01 --width 640 --height 480
• Launch a yarpview: yarpview
• Connect: yarp connect /grabber /yarpview/img:i udp

[francesco-romano]

Update: after I connect with udp, if I try to disconnect, the terminal hangs.
This seems to indicate that something is blocked somewhere.

Ok.. the disconnect hangs in a receive byte.
Probably the problem is before.

The send function of the UDP packet returns -1.
The error is the 40, which seems to be EMSGSIZE, i.e. message too long

[francesco-romano]

A fix for UDP has been pushed into https://github.com/robotology/yarp/tree/fix/637
The fix has been put only for macOS, to preserve back compatibility. I will ask @drdanz to test on linux, and somebody else on windows.

Regarding mcast I'm still debugging. The error this time is the 49, i.e. Can't assign requested address

[francesco-romano]

Regarding UDP, the previous commit was a bit rushed.
I'll try to summarise here the issue, and ask for advise to @lornat75 and @drdanz .

The code that manage the UDP (and MCAST) in yarp has 3 magic numbers hardcoded, (which can anyway be overwritten by (4) environment variables): size of socket buffer, size of internal read buffer and size of internal write buffer.

The open function first set the RECEIVING socket buffer to a magic number of 600000 (why?), but not the SENDING buffer.

Then, the internal buffers are set to other two magic numbers.

Now the questions are:

• how to choose the size of the internal buffers?
• how to choose the size of the socket buffer?

Should the socket buffers have the same size of the internal buffers? (I should say no, but I think they should be bigger than the internal ones).
What are reasonable defaults?

[francesco-romano]

also @apaikan can help in this!

[francesco-romano]

After a chat with @apaikan we decided the following thing (for now only for macOS to be back compatible)

By default the socket buffer size is the one of the system. The reason behind this is that (probably) the kernel engineers have chosen those parameters for some reason. Furthermore, as we experienced, those values change a lot between operating systems.
Of course the environmental variables to modify the buffer will still exist.

Then, the internal buffer size will by default set to be equal to the socket size (or a percentage? Like 0.9 ?).
Again environmental variables can change this behaviour. A warning will be issues if the size is not coherent with the socket size, i.e. if the internal send buffer size is bigger than the socket send buffer or viceversa if the internal read buffer size is less than the socket read size.

I'll start working on this issue as soon as I have some free time.

[francesco-romano]

Regarding mcast, I am trying to understand how it works.
A lot of webpages say that mcast is disabled by default on macOS, but compiling this C example (http://ntrg.cs.tcd.ie/undergrad/4ba2/multicast/antony/example.html) works.
So, either the example does not use mcast or we are doing something wrong on yarp.
Continuing debugging 😢

[francesco-romano]

Some updates on the issue:
I "translated" the example above from plain unix sockets to ACE:

• the writer simply opens a socket (open or join.. they have the same effect from the writer point of view) and sends data (send).
• the reader simply joins the multicast and calls recv (which is implemented in the plain UDP socket).

Comparing this implementation with the plain unix socket there is something "strange" to me:
In the writer unix implementation, the writer does not know anything about mcast. It simply writes to a "particular" IP. In ace, instead the send is implemented in the mcast subclass of dgram.
In the ace reader implementation, we do not specify to which local address we bind (while on plain sockets we can, e.g. any address 0.0.0.0), so I wonder which address we are binding.

Lastly to make the example work, I had to pass the following option to the constructor of the mcast object of the sender : OPT_BINDADDR_NO.
By passing the same option to https://github.com/robotology/yarp/blob/master/src/libYARP_OS/src/DgramTwoWayStream.cpp#L325 then also mcast starts working on YARP.

Before committing this change I'd like to understand better this problem anyway. Probably I'll take a look at ACE sources.