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 <r...@advancedcargo.eu>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 >> Openslp-devel@lists.sourceforge.net >> <mailto:Openslp-devel@lists.sourceforge.net> >> >> 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 Openslp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openslp-devel
