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.
[EMAIL PROTECTED] http://www.totalwire.it
cell: +39 346 7911896 tel: +39 051 302696
begin:vcard
fn:Sigismondo Boschi
n:Boschi;Sigismondo
org:TotalWire
adr:;;via Valdossola, 25/b;Bologna;BO;40134;Italy
email;internet:[EMAIL PROTECTED]
tel;work:+39 051 302696
tel;cell:+39 346 7911896
x-mozilla-html:FALSE
url:http://www.totalwire.it
version:2.1
end:vcard
_______________________________________________
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
