[erlang-questions] Multicast UDP sending question

Valentin Micic v@REDACTED
Tue Nov 17 20:45:29 CET 2009

From: Samuel Rivas [mailto:samuel.rivas@REDACTED] 

>You also need SO_REUSEADDR to bind listening sockets in the same UDP
>port to receive multicast traffic.
>If, for example, you open a socket listening in
>without that option, you wouldn't be able to bind a socket listening
>in in the same computer.

But... I do not agree with the above, this is why. The way to get multicast
working in Unix using system calls follows the sequence below:

1) Create a socket:

2) Bind the socket to a particular UDP port
   bind( int Socket, sockaddr* pBindInfo, sizeof( socktaddr_in)

3) add membership to a multicast addresses:
   int setsockopt(int Socket, int lvl, int optname, const void *optval,
socklen_t optlen);

Naming of the arguments may vary but option name (optname) that is used to
add multicast address membership is almost invariably defined as
IP_ADD_MEMBERSHIP. Option value (optval) in this case contains a structure
appropriate for IP_ADD_MEMBERSHIP which contains the actual multicast
address. One may add membership to any number of multicast addresses to the
same socket, by simply repeating the step 3).
Therefore it is possible to receive traffic for and
both coming over port 5353.

I've looked to see how reuse port works, and this is what I've found:
>From Richard Stevens (rstevens@REDACTED):

  This is a newer flag that appeared in the 4.4BSD multicasting code
  (although that code was from elsewhere, so I am not sure just who
  invented the new SO_REUSEPORT flag).

  What this flag lets you do is rebind a port that is already in use,
  but only if all users of the port specify the flag.  I believe the
  intent is for multicasting apps, since if you're running the same app
  on a host, all need to bind the same port.  But the flag may have
  other uses.  For example the following is from a post in February:

  From Stu Friedberg (stuartf@REDACTED):

       SO_REUSEPORT is also useful for eliminating the
       try-10-times-to-bind hack in ftpd's data connection setup
       routine.  Without SO_REUSEPORT, only one ftpd thread can
       bind to TCP (lhost, lport, INADDR_ANY, 0) in preparation for
       connecting back to the client.  Under conditions of heavy
       load, there are more threads colliding here than the
       try-10-times hack can accomodate.  With SO_REUSEPORT, things
       work nicely and the hack becomes unnecessary.

If I may put forward my 2c worth, this flag doesn't do anything useful but
creates confusion -- if we all reuse the same UDP port, who receives the
traffic in a case of unicast?


More information about the erlang-questions mailing list