<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Thanks Mike, for your prompt reply.<br>
<br>
On 7/19/2011 11:12 AM, Michael Smith wrote:
<blockquote
cite="mid:CAB=BY8vFGBkTj8ENYXgQDPGn7xQrZ8JyAVVn4QThkJfp7w6p+g@mail.gmail.com"
type="cite">
<div class="gmail_quote">On Tue, Jul 19, 2011 at 10:49 AM, Raymond
Lutz <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:raylutz@cognisys.com">raylutz@cognisys.com</a>></span>
wrote:<br>
<div> </div>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
<div bgcolor="#FFFFFF" text="#000000">QUESTIONS:<br>
1. I am curious why two listener entries are created for
each Blackberry listener. Ideas?<br>
</div>
</blockquote>
<div><br>
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.<br>
</div>
</div>
</blockquote>
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 the stream.)<br>
<blockquote
cite="mid:CAB=BY8vFGBkTj8ENYXgQDPGn7xQrZ8JyAVVn4QThkJfp7w6p+g@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<div>
</div>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
<div bgcolor="#FFFFFF" text="#000000"> 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?<br>
</div>
</blockquote>
<div><br>
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.<br>
</div>
</div>
</blockquote>
("threads" is a term that is probably technically incorrect.)<br>
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.<br>
<blockquote
cite="mid:CAB=BY8vFGBkTj8ENYXgQDPGn7xQrZ8JyAVVn4QThkJfp7w6p+g@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<div>
<br>
This is because something is keeping the connection alive.
Probably a blackberry problem.<br>
</div>
</div>
</blockquote>
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.<br>
<blockquote
cite="mid:CAB=BY8vFGBkTj8ENYXgQDPGn7xQrZ8JyAVVn4QThkJfp7w6p+g@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<div><br>
<br>
</div>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
<div bgcolor="#FFFFFF" text="#000000"> 3. Is there any good
way to deal with this? I was thinking the following might be
possible:<br>
a. maintain a cookie on the user device (Blackberry
Browser) related to each thread that is started.<br>
b. If the user attempts to start more than one thread,
kill any old threads, update the cookie.<br>
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.<br>
comments??<br>
</div>
</blockquote>
</div>
<br>
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.<br>
</blockquote>
Blackberry and most clients that I know of use cookies when they
access 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.<br>
<br>
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. <br>
<br>
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?<br>
<blockquote
cite="mid:CAB=BY8vFGBkTj8ENYXgQDPGn7xQrZ8JyAVVn4QThkJfp7w6p+g@mail.gmail.com"
type="cite">
<br>
It'd be better to figure out why the blackberry is misbehaving and
fix that.<br>
</blockquote>
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. <br>
<br>
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.<br>
<br>
I note that on the Blackberry website, it does not support RTSP
protocol for mp3 format.<br>
<a class="moz-txt-link-freetext" href="http://docs.blackberry.com/en/smartphone_users/deliverables/18349/711-01774-123_Supported_Media_Types_on_BlackBerry_Smartphones.pdf">http://docs.blackberry.com/en/smartphone_users/deliverables/18349/711-01774-123_Supported_Media_Types_on_BlackBerry_Smartphones.pdf</a><br>
<br>
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.)<br>
<br>
THANKS!<br>
--Ray<br>
<br>
<blockquote
cite="mid:CAB=BY8vFGBkTj8ENYXgQDPGn7xQrZ8JyAVVn4QThkJfp7w6p+g@mail.gmail.com"
type="cite"><br>
Mike<br>
<br>
<br>
<br>
<br>
<br>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
---------------------------------------
Raymond Lutz
Cognisys, Inc.
1010 Old Chase Ave., Bldg B
El Cajon (San Diego Cty), CA 92020 USA
Voice 619-447-3246
http//www.cognisys.com</pre>
</body>
</html>