[Ns-bugs] [Bug 943] Add a SO_BROADCAST socket option

[code@nsnam.ece.gatech.edu]

http://www.nsnam.org/bugzilla/show_bug.cgi?id=943





--- Comment #2 from Gustavo J. A. M. Carneiro <gjcarneiro at gmail.com>  2010-06-16 09:26:31 EDT ---
(In reply to comment #1)
> In principle I have no problems with the concept; I like to align with sockets
> when people have use cases for it.
> 
> I think it is applicable to Ipv4 datagram sockets only.  For stream sockets or
> for IPv6 we could either return -1 and set EINVAL, or else (keeping the return
> void as you have done) just unconditionally FATAL_ERROR ("Invalid for this type
> of socket"), and always return "false" for the Get() method.

Agreed regarding IPv6.  I checked olsrd, it does not seem to use the
SO_BROADCAST option for the IPv6 sockets, only for the IPv4 ones.

About returning void or an error code, the choice of returning void I made
based on the only other socket option method that I saw available:
BindToNetDevice().  However, setsockopt does return an int (0=ok, -1=error), so
I think it makes more sense to return some kind of error indicator.  In the
case of the Socket class, we seem to be using the same kind of 0 or -1 int
return for signalling errors...

> 
> Plus, as you mention, enforce it.

This might require changes deep in the bowels of IPv4, as it is not easy to
determine immediately whether a destination address is broadcast or not, you
have to look at the available interfaces in the host.  SendTo is the most
problematic one: doing the above iteration of host interfaces on a per-packet
basis is going to be slow without some sort of cache based optimization, and
adding a cache also wastes memory... really not the kind of decision I like to
make (lose-lose) :-/

-- 
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.