Aha. Ok. I just read about RTP and they argue that either RTPC or
other session management protocol should be used.
I'd guess that any sane protocol would use some kind of liveness
reporting from users. If recieving app crashes then the server
should recognize it in some reasonable time and stop se
If you are using RTP for the session, you may also use RTCP as a
back-channel for reception reports. However, this is not required.
On Mon, 2003-08-25 at 19:59, devik wrote:
> I would ignore multicast ane let it go thru as aparently
> regular dialup and ADSL users have no access to it. Thus
> I c
I would ignore multicast ane let it go thru as aparently
regular dialup and ADSL users have no access to it. Thus
I consider it to be more secured by ISPs.
Streaming audio/video, is not there some "feedback" channel
so that server knows when client is dead ? There should be
something like it IMHO.
For TCP that works. There are, however, UDP applications that are
one-way (e.g. streaming video/audio). Many multicast applications are
one-way.
On Mon, 2003-08-25 at 09:16, devik wrote:
> Hi,
>
> I got idea how to create anti-DDoS framework. I depicted
> it here: http://luxik.cdi.cz/~devik/qos
Hi,
I got idea how to create anti-DDoS framework. I depicted
it here: http://luxik.cdi.cz/~devik/qos/ddos-blackhole.htm
I'd appreciate opinions whether it could work. Please Cc
me in replies.
Thanks,
---
Martin Devera aka devik
Linux kernel QoS/HTB maintainer
htt
