[Icecast] Kicking duplicate connections

[Damian]

I see. However, it is often pretty easy to see that a duplicate connection is the same listener because the time connected to the server of the two connections is the same. In that case, I am wondering which would be the one to kick. 

> On 22 Dec 2019, at 23:39, Gavin Stephens <gavin at stephens.net.nz> wrote:
> 
> With NAT, also with carrier grade NAT becoming more poplular with ISP's yet to move to IPv6, if you have a very popular stream you could end up kicking valid listners behind the same IP.
> 
> 
>> On 23 December 2019 2:18:35 AM NZDT, Damian <db76 at riseup.net> wrote:
>> Hello fellow mailing list readers,
>> 
>> My question relates to multiple / duplicate connections to the ice cast server from the same IP address.
>> 
>> I am well aware that this is an issue that lies with the music player (listener agent) used by the listener. When a listener connects to the stream, sometimes it appears as two connections to the stream from the same IP address. This may last only a few seconds, or sometimes the listener may remain connected with two instances of the IP address. 
>> 
>> I’d like some advice on what is best practice in dealing with these duplicate connections. Many years ago, when I ran a shoutcast server, a developer wrote a script for me that would automatically kick one of the duplicate connections, so that only the first connection remained tuned in to the stream. 
>> 
>> I was considering reusing this script with the ice cast server. Would anyone advise against this practice? If so, for what reasons and would you advise an alteravie?
>> 
>> Regards
>> Damian
>> Icecast mailing list
>> Icecast at xiph.org
>> http://lists.xiph.org/mailman/listinfo/icecast
> 
> -- 
> Sent from Open Mail on Android._______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20191223/91685754/attachment.htm>