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
