[streaming] Re: Bug when a RSTP streaming is dirty closed ?

[Rémi Denis-Courmont]

Le Mercredi 1 Mars 2006 15:23, CACHET Nicolas a écrit :
> [00000299] [Media: canal0] access_output_udp private warning: send
> error: Connection refused [00000301] [Media: canal0]
> access_output_udp private warning: send error: Connection refused

> So, why VLC server continues to send datagrams that it knows they
> can't be received ?

That's a good point. VLC should probably stop sending in that case. On 
the other hand, I don't know how trustworthy ICMP error would be in 
that case, ie. how easily one can spoof them to carry out a denial of 
service. Also, I don't know how portable passing of ICMP errors back 
through send is (does it work on Windows? for instance), but that is 
not an excuse for not handling them.

My main concerns would rather be:

- the usability/reliability problems associated with tearing down a 
network stream automatically in case of would-be -transient- ICMP 
errors. At least ICMP errors should not happen with multicast, which 
eliminates the risk for most live UDP streaming use case. Perhaps 
someone with a more comprehensive experience in this area (Meuuh, 
TheDJ, Md... ?) could share his insight.

- that none of the mutiplexers and streaming plugins check for output 
errors... so even if we caused the UDP plugin to stop emitting packets, 
the server would continue to stream internally instead of releasing 
resources and printing an error message on the control session if it is 
still open.


In any case, implementing RTCP is the right answer. But it's most likely 
not going to happen so long as we have no developer to do that.

-- 
Rémi Denis-Courmont
http://www.simphalempin.com/home/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mailman.videolan.org/pipermail/streaming/attachments/20060302/2651a7aa/attachment.pgp