Re: Detecting Client bandwidth
Re: Detecting Client bandwidth
- Subject: Re: Detecting Client bandwidth
- From: Terry Lambert <email@hidden>
- Date: Mon, 6 Aug 2007 12:47:08 -0700
On Aug 6, 2007, at 11:16 AM, Justin C. Walker wrote:
On Aug 6, 2007, at 10:18 , Alan wrote:
Hi guys,
Are there any ways to detect/estimate the bandwidth of individual
clients connected to Darwin streaming server? I'm trying to
implement that when a client bandwidth is of lower speed, the
server will stream an inferior quality to the client etc.
Can anybody help me?
As a first step, you could contact a list that deals with the
streaming server. Check <http://lists.apple.com> to find them.
This list deals with the Darwin OS.
However, I think you will find that Josh is correct, and there are
only crude instruments available to user space in most modern OSs,
such as checking how full the send queue is at some (low granularity)
intervals.
For example, I'm pretty sure we don't maintain a weighted moving
average for bandwidth delay product that would be accessible to a
streaming server via via an ioctl() on a socket to see if that
connection is lagging. I'm also pretty sure there's no statistic on
pool retention time in the send queue (i.e. how full the socket send
side is at any one time, relative to drain rate).
It's not really clear if these are the figures of merit for making
this type of decision, but it's where I'd start, if I were looking.
If anyone on this list is looking for a PhD Thesis topic, this is in
general an area that's probably pretty wide open, since most work so
far has, I think, been more related to overall congestion control,
rather than QOS narrowing for narrower pipes (c.f. CMUs work on TCP
rate halving, window size reduction to improve server resource
utilization, packet shaping and window exaggeration to ensure
bandwidth sharing, etc.).
PS: I think the best approach you will likely find, as the author of a
streamin server, would be to put the sockets in non-blocking mode and
keep a relative count of the ratio of send request size vs. bytes of
data actually sent; this will give you some idea of how quickly/slowly
a given client is consuming a feed, which is probably the closes you
can come without research into new kernel support mechanisms.
-- Terry
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden