[Live-devel] GroupsockHelper.cpp and weird problems with long startuptimes for applications

[Morgan Tørvolt]

Having done some more research, I am lead to believe that the problem
could be that my server eth0 interface is connected to a cheap-ass
broadband router, which may or more probably may not support
multicast. I also have a firewall on that interface which might eat
the packet. It is also natural to use that packet as the default route
is trough there =)

As the server has two interfaces, and the eth1 interface is the one I
want the server running at, is there a way a can specify this when
creating the RTSPserver? It seems to me that this is not possible. I
get the 127.0.1.1 address anyway. If this address is nessesary to have
in things like SIP announce or other things that I know too little
about, I can see the use of using this method. For my part, I already
know the IP of the server, so I see no real reason for me to try to
figure it out. A quick-fix for me is to reduce the timeout time to
something like 100ms, but the way this is done seems sub-optimal to
me. Would you be interested in me rewriting this
ourSourceAddressForMulticast function Ross, doing things a bit
differently (i.e testing on all interfaces except 127 in parallel,
choosing the fastest interface, and if no success use the lo 127
interface address? I cannot test this on anything but amd64 linux
though.


Regards
Morgan Tørvolt

On 16/02/2008, Morgan Tørvolt <morgan.torvolt at gmail.com> wrote:
> Hi all
>
> I am having some weird problems at the moment. I am running a server
> and a laptop with the exact same kernel and software (obviously
> different hardware), and having some strange problems with that.
>
> On my laptop, starting the testOnDemandRTSPServer takes no time at
> all. On my server, the application uses a few seconds to start.
> Running valgrind and killing the process while in this "waiting state"
> at the beginning tells me:
>
>
> ==26912== Process terminating with default action of signal 2 (SIGINT)
> ==26912==    at 0x568D053: select (in /lib/libc-2.6.1.so)
> ==26912==    by 0x448116: readSocket(UsageEnvironment&, int, unsigned
> char*, unsigned, sockaddr_in&, timeval*) (in
> /home/mt/live/testProgs/testOnDemandRTSPServer)
> ==26912==    by 0x44868B:
> ourSourceAddressForMulticast(UsageEnvironment&) (in
> /home/mt/live/testProgs/testOnDemandRTSPServer)
> ==26912==    by 0x428EC0: RTSPServer::rtspURLPrefix(int) const (in
> /home/mt/live/testProgs/testOnDemandRTSPServer)
> ==26912==    by 0x428EEC: RTSPServer::rtspURL(ServerMediaSession
> const*, int) const (in /home/mt/live/testProgs/testOnDemandRTSPServer)
> ==26912==    by 0x40223A: announceStream(RTSPServer*,
> ServerMediaSession*, char const*, char const*) (in
> /home/mt/live/testProgs/testOnDemandRTSPServer)
> ==26912==    by 0x4023AE: main (in
> /home/mt/live/testProgs/testOnDemandRTSPServer)
>
>
> Since "readSocket(UsageEnvironment" only exists in GroupsockHelper.cpp
> and GroupsockHelper.hh, and there is only one select in the entire
> file, I am pretty sure the delay happens at line 229 in
> GroupsockHelper.cpp.
>
> The server seems to also output a different IP address than the laptop
> as well, laptop using eth0, while the server uses... eh, some other
> address:
>
> "mpeg4ESVideoTest" stream, from the file "test.m4e"
> Play this stream using the URL "rtsp://127.0.1.1:8554/mpeg4ESVideoTest"
>
> It seems from the trace that the ourSourceAddressForMulticast is the
> sinner. Firstly, what does multicast have to do with the RTSP server?
> Is that not purely unicast? Secondly, how can I remove this delay? It
> is not critical, but quite annoying, especially the fact that my lousy
> laptop "performs better" from the client point of view =)
>
> As mentioned, running the exact same kernel, so multicast support
> should be the same in both. They are the latest realtime kernels from
> Ubuntu.
>
> Thanks for any help with this.
>
> -Morgan Torvolt-
>