[Ns-bugs] [Bug 943] Add a SO_BROADCAST socket option
code at nsnam.ece.gatech.edu
Wed Jun 16 06:26:31 PDT 2010
--- 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.
More information about the Ns-bugs