| View previous topic :: View next topic |
| Author |
Message |
Solbu Guest
|
Posted: Fri Jul 22, 2005 3:04 am Post subject: Reserved / priority listeners |
|
|
Say I have a (relay) stream supporting 10 listeners.
Lets also say 10 listeners are connected and I want to connect. Then I can not connect until someone disconnects.
Is it possible to configure the server to give me or my IPadress priority over anyone else, so that one connected client is killed/disconnected by the server in order to open a "seat" for me if the limit is reached?
I have heard that Shoutcast support this.
I don't want to switch to Shoutcast only for this, but I will if I have to.
--
Greetings from Norway |
|
| Back to top |
|
 |
karlH Code Warrior

Joined: 13 Jun 2005 Posts: 5476 Location: UK
|
Posted: Fri Jul 22, 2005 2:38 pm Post subject: Re: Reserved / priority listeners |
|
|
| Solbu wrote: |
Say I have a (relay) stream supporting 10 listeners.
Lets also say 10 listeners are connected and I want to connect. Then I can not connect until someone disconnects.
Is it possible to configure the server to give me or my IPadress priority over anyone else, so that one connected client is killed/disconnected by the server in order to open a "seat" for me if the limit is reached?
|
There is no in-built mechanism for this, the only way currently I can see it being implemented is by using the auth url component in the kh branch. A PHP script could issue a killclient request before sending back an ok to icecast for the new listener connect.
Whether a better mechanism/policy can be defined I'm not sure |
|
| Back to top |
|
 |
Anonymous Guest
|
Posted: Mon Jul 25, 2005 7:17 pm Post subject: |
|
|
i think this would a pretty good feature,
like the feature in shoutcast: reserved ip,
a webased option to add ip's and then on connect it will check this array of ip's to see if it exists, if it does then kill the longest connection or something.
iv i could code in c i would add this myself, unfortunatly all i know is c#.net
regards |
|
| Back to top |
|
 |
Anonymous Guest
|
Posted: Mon Jul 25, 2005 11:24 pm Post subject: |
|
|
with the url features now available it should be fairly simple with a web server and PHP/PERL ....
i suspect having it disconnect the longest listener could be tricky, but more just return server full , and it would be in reserved IP mode only ( in a basic form )
I might have a play around with some PHP if it would be useful to you.
Andrew. |
|
| Back to top |
|
 |
karlH Code Warrior

Joined: 13 Jun 2005 Posts: 5476 Location: UK
|
Posted: Tue Jul 26, 2005 1:30 am Post subject: |
|
|
The key thing with the URL listener auth is to offload listener acceptance/denial to something more flexible. We could add IP blocking into icecast but that may not be flexible enough. Some may want ranges of IPs blocking, useragent filtering, selection based on time of day or maybe involve something more complex like looking up user details from an SQL database.
I have also trying out an optional listener timelimit setting which can only currently be set via the URL module, eg send back a header like
icecast-auth-timelimit: 900
and the listener will drop after 15 mins of streaming, if people would want that then it can be merge into trunk and maybe expanded on, obviously htpasswd is not going to be as flexible in such cases
karl. |
|
| Back to top |
|
 |
Anonymous Guest
|
Posted: Tue Jul 26, 2005 7:04 pm Post subject: |
|
|
well i definately say the disconnect timer is useful to me, for all sorts of reasons ( but then that is why i asked for it ... a while ago )
another one to add ... and I'll post it, to see if it prompts other discussion, would be to disconnect a slot, when someone else connects ...
ie.
icecast-auth-disconnect: <slot_id>
as you know the ID someone authenticated with, as this is sent in the URL request, just in case no everyone is aware of what is sent
action=auth
client=<slot_id>
server=<server_ip>
port=<server_port>
mount=<mount_point_name>
user=<username>
pass=<password>
ip=<client_ip>
agent=<client agent>
so you could put this into a database, so when the request comes in again, with the same username, you can allow ( or reject ) , but if you allow , sent back the ID of the other session, to disconnect it, so allowing only one user with a username/password at any time.
Discuss ?
Andrew.
ps. sorry kinda hijacked the thread ... oops |
|
| Back to top |
|
 |
gee2803
Joined: 11 Aug 2006 Posts: 48
|
Posted: Tue Nov 15, 2011 10:52 pm Post subject: |
|
|
| has this changed in the newer versions? Is there already another fixed solution in the configs for this? |
|
| Back to top |
|
 |
|