[Icecast] Orphan threads with Cellphone (Blackberry) player
raylutz at cognisys.com
Tue Jul 19 12:38:19 PDT 2011
Thanks Mike, for your prompt reply.
On 7/19/2011 11:12 AM, Michael Smith wrote:
> On Tue, Jul 19, 2011 at 10:49 AM, Raymond Lutz <raylutz at cognisys.com
> <mailto:raylutz at cognisys.com>> wrote:
> 1. I am curious why two listener entries are created for each
> Blackberry listener. Ideas?
> Icecast doesn't make any attempt to ensure that only one connection is
> made from any one IP - that can be entirely legitimate for many
> reasons. This means two things are connecting to icecast. It could be
> a blackberry bug.
I did not want to imply that it was always incorrect for the same IP
address to be connected, but in this case, I know that it is the
blackberry device and the earlier connections are orphans and
unnecessary (because I've killed them and the device continues to play
> 2. I don't have any theory as to why new threads are started even
> though the old threads persist. (they continue redundantly until
> the handset is turned off for at least 5 minutes, which appears
> only to bog down the icecast server with unnecessary listener
> threads). Ideas?
> You've consistently used "threads" here where there are most certainly
> no additional threads being started. There are additional connections,
> though. Icecast scales very well with more connections; it's not
> really accurate to suggest that this "bogs down" the server.
("threads" is a term that is probably technically incorrect.)
Each listener connection "bogs down" the server to the extent that one
additional worthless listener connection is being maintained. This means
bandwidth being used that does no good. Have 10,000 blackberrys
listening and it will be like 50,000 or 100,000 regular listeners. My
calculations are that with the bandwidth I have allocated, I can stand
21,000 listeners, but I have a feeling icecast will choke in some other
way long before that.
> This is because something is keeping the connection alive. Probably a
> blackberry problem.
Clearly, it is likely because we don't have a direct connection between
the icecast server and the listener device since it goes through the
wireless providers intermediate servers (in this case, Verizon), and
they maintain the connection with icecast even though the final target
device has dropped the connection.
> 3. Is there any good way to deal with this? I was thinking the
> following might be possible:
> a. maintain a cookie on the user device (Blackberry Browser)
> related to each thread that is started.
> b. If the user attempts to start more than one thread, kill
> any old threads, update the cookie.
> c. Provide a way to kill the thread from the browser
> interface, such as sending a message to the server when the user
> exits the web page, utilizing cookie information.
> You could build such an interface external to icecast, and manage
> killing listeners through the admin interface. This doesn't belong
> inside icecast. Note also that the vast majority of clients do NOT use
> a full web stack to connect to icecast so cookies couldn't be used. If
> you know the blackberry does, you can manage that externally.
my website page before a player is started. I don't know what they do
once the player is started. (Computer-based players don't seem to have
the problem I am reporting) and with that, it would be at least possible
to do the cookie trick to allow the user to click on a disconnect button
and stop the connection, as well as ensuring only one connection per user.
Another option I have been thinking of is making a App that could be
downloaded in Blackberry App World and installed on the device. The
stream would be started and "cleaned up" by the App when the user stops it.
So, in a general sense, is there any means for a given listener to know
which connection they are on (i.e. the number which is not listed in the
Admin "List Clients" display but is displayed when you kill a listener)
and a way to kill the named listener?
> It'd be better to figure out why the blackberry is misbehaving and fix
Indeed. And if someone has information about how to deal with this
issue, that is what I am interested in finding out. It is not
necessarily a problem with the icecast server component, but at the same
time, if a cell-phone player does not work "out of the box" then
something is wrong with the entire solution.
Blackberrys work this way, and so in a sense, they are not
"misbehaving". This sort of behavior is what we will need to deal with,
as it will be all but impossible to change the behavior of 70 million
(or whatever the number is) players.
I note that on the Blackberry website, it does not support RTSP protocol
for mp3 format.
I wonder if you could comment on RTSP protocol and whether this may be
the issue (although I was under the impression that icecast did not rely
on RTSP protocol.)
1010 Old Chase Ave., Bldg B
El Cajon (San Diego Cty), CA 92020 USA
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Icecast