[Live-devel] Late binding fix in 2010.01.15 version not yielding video...

Thu Jan 21 12:42:15 PST 2010

Ross:

No multicast packets are received with the 2010-01-15 version for which you
provided the fix.  I looked at the TCP/IP stack source and it appears that
once a socket is bound it cannot be rebound.  As a test I commented out the
'bind' code block in the setupDatagramSocket() function in the
"GroupsockHelper.cpp" file and let the changePort() function in the
"NetInterface.cpp" file perform the 'bind' and multicast packets then were
received by VLC and video displayed.  I hope this helps and sorry for the
'false' positive on the first go-round.

Best Regards,

-- 
Rob Krakora
Senior Software Engineer
MessageNet Systems
101 East Carmel Dr. Suite 105
Carmel, IN 46032
(317)566-1677 Ext. 206
(317)663-0808 Fax

On Thu, Jan 21, 2010 at 11:13 AM, Robert Krakora <rob.krakora at gmail.com>wrote:

> My bad,
>
> SO_REUSEADDR allows binding to an address that is in a TIME_WAIT state
> while SO_REUSEPORT allows multiple processes to bind to the same address.
> This has nothing to do with rebinding...I will keep looking...
>
>
> On Thu, Jan 21, 2010 at 10:58 AM, Robert Krakora <rob.krakora at gmail.com>wrote:
>
>> Ross:
>>
>> It looks like kernel 2.6.18-128.1.10.el5 utilized in CentOS 5.3 does not
>> implement SO_REUSEPORT (see commented out SO_REUSEPORT below from "socket.h"
>> file for this kernel and the comment about it's needed implementation in
>> *bold red*).  Otherwise I believe your fix would have worked.  I did not
>> see an error message on the re-bind code like I would have expected though.
>> I am going to retest and put in some breakpoints.
>>
>> #ifndef _ASM_SOCKET_H
>> #define _ASM_SOCKET_H
>>
>> #include <asm/sockios.h>
>>
>> /* For setsockopt(2) */
>> #define SOL_SOCKET    1
>>
>> #define SO_DEBUG    1
>> #define SO_REUSEADDR    2
>> #define SO_TYPE        3
>> #define SO_ERROR    4
>> #define SO_DONTROUTE    5
>> #define SO_BROADCAST    6
>> #define SO_SNDBUF    7
>> #define SO_RCVBUF    8
>> #define SO_SNDBUFFORCE    32
>> #define SO_RCVBUFFORCE    33
>> #define SO_KEEPALIVE    9
>> #define SO_OOBINLINE    10
>> #define SO_NO_CHECK    11
>> #define SO_PRIORITY    12
>> #define SO_LINGER    13
>> #define SO_BSDCOMPAT    14
>> */* To add :#define SO_REUSEPORT 15 */*
>> #define SO_PASSCRED    16
>> #define SO_PEERCRED    17
>> #define SO_RCVLOWAT    18
>> #define SO_SNDLOWAT    19
>> #define SO_RCVTIMEO    20
>> #define SO_SNDTIMEO    21
>>
>> /* Security levels - as per NRL IPv6 - don't actually do anything */
>> #define SO_SECURITY_AUTHENTICATION        22
>> #define SO_SECURITY_ENCRYPTION_TRANSPORT    23
>> #define SO_SECURITY_ENCRYPTION_NETWORK        24
>>
>> #define SO_BINDTODEVICE    25
>>
>> /* Socket filtering */
>> #define SO_ATTACH_FILTER        26
>> #define SO_DETACH_FILTER        27
>>
>> #define SO_PEERNAME        28
>> #define SO_TIMESTAMP        29
>> #define SCM_TIMESTAMP        SO_TIMESTAMP
>>
>> #define SO_ACCEPTCONN        30
>>
>> #define SO_PEERSEC             31
>> #define SO_PASSSEC        34
>>
>> #endif /* _ASM_SOCKET_H */
>>
>>
>> Best Regards,
>>
>> --
>> Rob Krakora
>> Senior Software Engineer
>> MessageNet Systems
>> 101 East Carmel Dr. Suite 105
>> Carmel, IN 46032
>> (317)566-1677 Ext. 206
>> (317)663-0808 Fax
>>
>> On Thu, Jan 21, 2010 at 8:26 AM, Robert Krakora <rob.krakora at gmail.com>wrote:
>>
>>> Ross:
>>>
>>> I will debug this and let you know what is going on.  Multicast data was
>>> arriving per Wireshark.  However, I did not capture the RTSP traffic...I
>>> cannot see the video as the location is remote.  It was bad judgement on my
>>> part to indicate to you that it was working prematurely.  I will have
>>> someone at the site set up the camera and I will get you some data today.
>>> Sorry, I have a lot of things on my platter and I rushed to judgement.  ;-)
>>>
>>> Best Regards,
>>>
>>> --
>>> Rob Krakora
>>> Senior Software Engineer
>>> MessageNet Systems
>>> 101 East Carmel Dr. Suite 105
>>> Carmel, IN 46032
>>> (317)566-1677 Ext. 206
>>> (317)663-0808 Fax
>>> On Wed, Jan 20, 2010 at 6:19 PM, Ross Finlayson <finlayson at live555.com>wrote:
>>>
>>>>  The fix with which you provided me for the multicast destination
>>>>> address embedded in the SETUP response does not appear to be yielding video.
>>>>>
>>>>
>>>> Well, beforehand you told me that it worked OK!
>>>>
>>>> Anyway, the fix was to reimplement the "Socket::changePort()" function
>>>> (in "groupsock/NetInterface.cpp") to call "bind()" (with the new port
>>>> number), rather than closing and then reopening the socket (which is what
>>>> both the old version and your hack did).  Could you please figure out why
>>>> the "changePort()" function is not working for you?  Unfortunately, I can't
>>>> test this myself, because I don't have server that works the way yours does.
>>>> --
>>>>
>>>> Ross Finlayson
>>>> Live Networks, Inc.
>>>> http://www.live555.com/
>>>> _______________________________________________
>>>> live-devel mailing list
>>>> live-devel at lists.live555.com
>>>> http://lists.live555.com/mailman/listinfo/live-devel
>>>>
>>>
>>>
>>
>
>
> --
> Rob Krakora
> Senior Software Engineer
> MessageNet Systems
> 101 East Carmel Dr. Suite 105
> Carmel, IN 46032
> (317)566-1677 Ext. 206
> (317)663-0808 Fax
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20100121/7511c23f/attachment.html>