That doesn't matter, because *TCP* packets will still be arriving
(on the TCP socket), and will be handled. This is a Red Herring.
No, that TCP socket has been closed - and the corresponding socket
ID refers occasionally to an UDP socket within the same call to
SingleStep - if it was a red herr
Yes you're right!
I missed the minus before the 10 before the second example and got confused!
Thanks
_
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Ross Finlayson
Sent: Monday, November 10, 2008 9:24 PM
To: LIVE555 Streaming Media - development & use
Subject: Re:
Ross Finlayson wrote:
That doesn't matter, because *TCP* packets will still be arriving (on
the TCP socket), and will be handled. This is a Red Herring.
No, that TCP socket has been closed - and the corresponding socket ID
refers occasionally to an UDP socket within the same call to SingleStep
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.
T
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 the
