site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com Hi guys, -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... On Aug 6, 2007, at 11:16 AM, Justin C. Walker wrote: On Aug 6, 2007, at 10:18 , Alan wrote: 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. This email sent to site_archiver@lists.apple.com