<br><br><div class="gmail_quote">On Fri, Oct 1, 2010 at 5:05 PM, Ross Finlayson <span dir="ltr"><<a href="mailto:finlayson@live555.com">finlayson@live555.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div><div class="im">
<blockquote type="cite">I have done some investigation on this
issue and here are the results and suggestions.</blockquote>
<blockquote type="cite"><br></blockquote>
<blockquote type="cite">1. You were right, it works on
freeBSD , but see 2.</blockquote>
<blockquote type="cite"><br></blockquote>
<blockquote type="cite">2. This is not a Linux bug</blockquote>
<div><br></div>
</div><div>I guess we'll just have to disagree on this.</div><div class="im">
<div><br></div>
<div><br></div>
<blockquote type="cite">We know that one should not bind() to a
multicast address</blockquote>
<div><br></div>
</div><div>Agreed :-)</div><div class="im">
<div><br></div>
<div><br></div>
<blockquote type="cite">, but according to the kernel developers
and other multicast developers this is intended in case you want to
receive only from one address and port and not all. It depends on
whats needed, so no bug..</blockquote>
<blockquote type="cite">.</blockquote>
<blockquote type="cite"><a href="http://jungla.dit.upm.es/%7Ejmseyas/linux/mcast.lj/mcast-lj.html" target="_blank">http://jungla.dit.upm.es/~jmseyas/linux/mcast.lj/mcast-lj.html</a> (shows a bind is required)</blockquote>
<blockquote type="cite"><a href="http://marc.info/?l=linux-netdev&m=121579883022264&w=2" target="_blank">http://marc.info/?l=linux-netdev&m=121579883022264&w=2</a></blockquote>
<blockquote type="cite"><a href="http://marc.info/?l=linux-netdev&m=121580189427089&w=2" target="_blank">http://marc.info/?l=linux-netdev&m=121580189427089&w=2</a></blockquote>
<div><br></div>
<div><br></div>
</div><div>I don't agree with the arguments made here. In
particular:</div><div class="im">
<div><br></div>
<blockquote type="cite">
<blockquote>That's how it has always worked in the original socket
implementation (BSD) and derivatives.</blockquote>
</blockquote>
<div><br></div>
</div><div>is most definitely not true, because (as you have discovered
yourself) it doesn't work this way in FreeBSD.</div>
<div><br></div>
<div>I also don't agree with the claim that "Multicast addresses,
like unicast addresses, are for the entire</div>
<div>machine, not just the socket that does the join", because
the IP_ADD_MEMBERSHIP operation is explicitly done on a socket (i.e.,
using "setsockopt()"). It also seems wrong that a
process should have the potential to - by joining a multicast group -
control which packets that are received by a separate process.
(This is arguably a security violation.)</div>
<div><br></div>
<div>In any case, this is all a moot point, because I'm not going to
be changing the LIVE555 code to bind to the multicast address (when
creating a multicast 'groupsock'), because in the past - when this
suggestion has been made - some people have discovered and reported
that it doesn't work for them. It does not appear to be portable
across different OSs, so I can't put it in the released code.
It's not inconceivable that sometime in the future I might make a
change to support this, but have it #ifdef'd out by default.
This is not a high priority, though, and the whole "groupsock"
interface will eventually be replaced anyway (to make it more
consistent with the "liveMedia" object model). So it
might not happen for a while, if ever. Sorry.</div></div></blockquote><div><br>Thank you Ross, <br>I do agree about the portability issue and do undestand you reasons not wanting to include it in main code.<br>Perhaps if it ever works, an ifdef solution may make the most sence.<br>
<br>As for the binding, the linux net folks have this undestanding, I am not going to argue on that one, but explains why there is no officeal patch for linux. <br><br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div>
<div><br></div>
<div>In the meantime, you *might* be able to get the effect you want
by making the following small change to
"liveMedia/MediaSession.cpp", and also changing
"groupsock/GroupsockHelper.cpp" to replace the line</div>
<div> if
(port.num() == 0) addr = ReceivingInterfaceAddr;</div>
<div>with</div>
<div> addr =
ReceivingInterfaceAddr;</div>
<div><br></div>
<div>(or, you could patch your Linux kernel :-)</div>
<div><br></div>
<div>*** MediaSession.cpp.save
Fri Oct 1 05:49:35 2010<br>
--- MediaSession.cpp Fri Oct 1
06:02:43 2010<br>
***************<br>
*** 568,573 ****<br>
--- 568,574 ----<br>
Boolean MediaSubsession::initiate(int useSpecialRTPoffset)
{<br>
if (fReadSource != NULL) return True; // has
already been initiated<br>
<br>
+ netAddressBits savedReceivingInterfaceAddr =
ReceivingInterfaceAddr;<br>
do {<br>
if (fCodecName == NULL) {<br>
env().setResultMsg("Codec is unspecified");<br>
***************<br>
*** 579,584 ****<br>
--- 580,586 ----<br>
struct in_addr tempAddr;<br>
tempAddr.s_addr =
connectionEndpointAddress();<br>
// This could
get changed later, as a result of a RTSP "SETUP"<br>
+ if (IsMulticastAddress(tempAddr.s_addr))
ReceivingInterfaceAddr = tempAddr.s_addr;<br>
<br>
if (fClientPortNum != 0) {<br>
// The sockets' port
numbers were specified for us. Use these:<br>
***************<br>
*** 892,897 ****<br>
--- 894,900 ----<br>
return True;<br>
} while (0);<br>
<br>
+ ReceivingInterfaceAddr =
savedReceivingInterfaceAddr;<br>
delete fRTPSocket; fRTPSocket = NULL;<br>
delete fRTCPSocket; fRTCPSocket = NULL;<br>
Medium::close(fRTCPInstance); fRTCPInstance =
NULL;</div><div class="im">
<pre>--
</pre>
<div><br></div></div></div></blockquote><div><br>Thanks for the provided patch, I was really looking for some guidance after hours of unsuccessful mods to the Groupsock and binding but still same behaiviour. <br>Unfortunately none has worked , neither does the above which really had me hoping for a while. <br>
<br>Any ideas? Did it work for you when you tried it ?<br><br>I think the reason its not working is socket requires GroupAddress to bind to in adition to ifaddress. <br><br>According to the linux folks the combination of mcastaddress:port is the one we have to bind to isolate sockets, else binding on the interface we get all traffic to all ports on the interface since we only bind to port without desitnation.<br>
<br>In any case thanks for all your help, I will still be looking for some work around in the groupsock and in my code before patching the kernel, but so far no luck.<br><br>Does anyone know of a patch for kernles 2.6.29 and above ?<br>
<br>P.S is UDP performance in freeBSD 8.x poor or is it just me?<br><br>Thanks again. <br><br>Zed<br><br><br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div><div class="im"><div>
Ross Finlayson<br>
Live Networks, Inc.<br>
<a href="http://www.live555.com/" target="_blank">http://www.live555.com/</a></div>
</div></div>
<br>_______________________________________________<br>
live-devel mailing list<br>
<a href="mailto:live-devel@lists.live555.com">live-devel@lists.live555.com</a><br>
<a href="http://lists.live555.com/mailman/listinfo/live-devel" target="_blank">http://lists.live555.com/mailman/listinfo/live-devel</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br>Zdenek Bouresh<br>NextStream LTD.<br><br>The information contained within this email transmission and any attachments is confidential and intended solely for the attention and use of the named individual addressee(s) or entity. It may not be legally revealed or be disclosed to any other person or third party without the express authority (prior written approval) of NextStream LTD and/or the original recipient, or the intended recipients, or both. If you are not the intended recipient, you must not disclose, copy, distribute, print, rely on or retain this message or any part of it. The information contained within is strictly prohibited. If you have received this email in error please notify the sender by reply, and delete this message from your email system(s). Any hard copies must also be destroyed.<br>