[Live-devel] bug in BasicTaskScheduler.cpp ?

[Sigismondo Boschi]

Ross Finlayson wrote:
> To my knowledge, there is nothing wrong with the current 
> "BasicTaskScheduler" code.
> 
> Did you upgrade to the very most recent version (2008.11.04) of the 
> code?  That version fixed a bug similar to what you seem to be seeing: 
> sockets were sometimes not being closed (and their associated event loop 
> handlers not being removed) when streaming RTP-over-TCP.
Yes, I upgraded up to this last one: I have the problem with it too. 
There are two points:

1. I do not know whether it is reasonable that I want to close and 
reopen the socket in the event loop. I have interpreted "yes" looking to 
your examples - but I need a very cold restart - reopening the client 
connections. Is this reasonable?

2. What happen is very tricky, it has taken some time to understand why 
it was getting stuck after some BYEs. Even if RTP-over-TCP is used, the 
UDP handlers are registered. They never get called because the select in 
SingleStep never "activate" them, since there are no UDP packets 
incoming. Let's say for example:
   socket    handler
   2000      TCP
   2100      RTP-UDP
   2200      RTCP-UDP
only the first one result activated in "readSet" after the select in 
SingleStep, and get successfully selected again in the TCP handler.

On an incoming BYE, the call fDelayQueue.HandleAlarm() calls my "reset 
connections" handler: such sockets get closed, and new one opened and 
replace the old one in fReadSet. Nothing strange happens when they are 
different socket ids, because of the checks:

if (FD_ISSET(handler->socketNum, &readSet) &&
     FD_ISSET(handler->socketNum, &fReadSet) /* sanity check */ &&

However it happens quite frequently (20% of the times) that after the 
reopen the TCP socket id is "relocated" (I am using windows xp - I do 
not know whether with linux is the same, however in principle it can 
happen with any OS):

   socket    handler
   2300      TCP
   2000      RTP-UDP
   2100      RTCP-UDP

So the "if" passes and the handler called is RTP-UDP on the UDP 
connection. No packets incoming there, so the handler waits 
indefenitevly. The bug I have observed is related to the fact that it is 
assumed that fDelayQueue.HandleAlarm() does not perform any reconnection.

Moving the call to fDelayQueue.HandleAlarm() AFTER the call to the 
handlers solve this problem.
Another solution could be to call fDelayQueue.HandleAlarm() only upon 
timeout of the select in SingleStep, the handlers only upon socket 
"selection" of the select (only if data are incoming). Fine tune for 
cases where both events happens - but let only one of the two get executed.
A 3rd one should be not to register the UDP handlers at all.

> 
> Note that any time a socket gets closed, its associated event loop 
> handler should also get removed (using 
> "TaskScheduler::turnOffBackgroundReadHandling()"), so that it does not 
> get looked at again by "select()".  I believe that the current version 
> of the code does this properly.
Yes, I have seen it - and that's why I can not reopen directly in the 
BYE handler (it is destroyed - I did not know when I did it, but now the 
structure is very clear - nice job!), but I need to schedule an event. 
The called handler is correct - it is the fact that it has been changed 
in the middle of SingleStep that let it become one of the useless UDP 
handlers (either RTP or RTCP) instead of the TCP one.

I hope this is clearer now.

Regards,
    Sigismondo


-- 
------------------------------------------------------------------
Sigismondo Boschi, PhD                     TotalWire S.r.l.
s.boschi at totalwire.it                      http://www.totalwire.it
cell: +39 346 7911896                      tel:  +39 051 302696
-------------- next part --------------
A non-text attachment was scrubbed...
Name: s_boschi.vcf
Type: text/x-vcard
Size: 275 bytes
Desc: not available
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20081111/18d15008/attachment.vcf>