Correction. More multi-nic testing on OSX showed a similar problem with the list. One of those days, I guess. :)
So the darwin version now calls socket() and closes it after the sendto. While this is more portable, I kept it in the Darwin #ifdef, because I wasn't sure if we wanted to create extra sockets on already working platforms. --Nick On Thu, Aug 12, 2010 at 5:24 PM, Nick Wagner <[email protected]> wrote: > I had meant the source IP address, not the source port. > > Anyway, I've added the patch which does a search for the unicast socket. > I've made this change a Darwin-only change for two reasons: 1) things work > correctly the way they are now on Linux. 2) Linux is more selective about > data sent to a socket bound to a network interface -- just picking the first > unicast socket caused the wrong source IP address to be in the packet. > > --Nick > > > > On Thu, Aug 12, 2010 at 4:32 PM, Roel van de Kraats <[email protected] > > wrote: > >> Hi Nick, >> >> >> On 08/12/2010 12:42 AM, Nick Wagner wrote: >> >>> I agree that it's not ideal for the multicast-bound socket to be used for >>> unicast. For one thing, on some platforms the binding address affects the >>> source address, which can be confusing for someone trying to respond (or >>> sniff). >>> >> But since that's how slp was designed (using the same port for both >> unicast and multicast access, instead of e.g. publishing the unicast port to >> use through an advert) this is what we'll have to live with. >> >> After looking more closely at the situation you described, it also makes >> sense to reply from the same port as on which the incoming (unicast?) >> datagram was received. Isn't that how e.g. firewalls determine whether data >> is allowed to pass? But if this mechanism doesn't work always, it is indeed >> perhaps better to pick another port as you suggested. Any experts on this? >> >> >>> So, now's our opportunity for fixing the problem. The >>> socket()/sendto()/close() method seems the simplest, but if possible I'd >>> prefer a more elegant solution using sockets we've already bound. I could >>> walk the G_IncomingSocketList to find the first socket that has >>> can_send_mcast set to true -- that is only set on the unicast UDP socket, >>> marking it for use for multicast sending in slpd_knownda.c >>> >> If you think this is faster than simply creating a new socket, that's >> probably the best solution. >> >> Roel >> >>> >>> --Nick >>> >>> Hi Nick, >>> >>> In my opinion, a socket bound to a multicast address (c.q. the >>> standard slp port) should never be used for sending data, since a >>> reply (as in a 'private conversation') will need to be sent to >>> that 'public' socket. Not only is this somewhat unpretty, it also >>> gives problems when other processes bind to the same multicast >>> address/port as well. It is uncertain who will receive the reply >>> then. But since SLP defines that unicasts can be sent to the >>> standard multicast port, multiple processes binding won't work >>> properly anyway. >>> >>> Please correct me if I'm wrong here; this is just my idea of how >>> things work (after a lot of testing). >>> >>> BR, >>> Roel >>> >>> >>> >>> --Nick >>> >>> >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> This SF.net email is sponsored by >>> >>> Make an app they can't live without >>> Enter the BlackBerry Developer Challenge >>> http://p.sf.net/sfu/RIM-dev2dev >>> >>> >>> _______________________________________________ >>> Openslp-devel mailing list >>> [email protected] >>> <mailto:[email protected]> >>> >>> https://lists.sourceforge.net/lists/listinfo/openslp-devel >>> >>> >>> >>> >> >
------------------------------------------------------------------------------ This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev
_______________________________________________ Openslp-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openslp-devel
