On 08/11/2010 10:45 PM, Nick Wagner wrote:
> As a simpler option, I could create a new socket before each sendto
> and close it afterwards, but creating a new socket each time feels a
> little unnecessary.
>
> On Wed, Aug 11, 2010 at 3:29 PM, Nick Wagner <ne...@wingedbeast.org
> <mailto:ne...@wingedbeast.org>> wrote:
>
> I've run into a problem on IPv4 OS X 10.6. I haven't tested IPv6.
> It appears that a socket bound to a multicast address is unable
> to send data -- sendto() fails with EADDRNOTAVAIL when sending to
> a unicast or multicast address. This worked in 10.5 and 10.4, and
> of course works on Linux and Windows. If the socket is bound to an
> interface address, the sendto works as expected, no matter the
> destination address. The only code this seems to affect is
> slpd_incoming.c : IncomingDatagramRead(), where the unicast
> response is sent on the receiving socket. I could use the
> SLPDOutgoingConnect/SLPDOutgoingDatagramWrite mechanism to attempt
> to fix this, but this seems a bit overkill for what was originally
> a sendto(). Since the last incoming socket is for unicast we
> might get away with sending to that one, but that seems a bit of a
> hack that will break later. Suggestions?
>
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
> 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
