On Thu, Jan 15, 2009 at 1:26 PM, Max Kellermann <m...@duempel.org> wrote: > On 2009/01/14 19:11, Stefan Monnier <monn...@iro.umontreal.ca> wrote: >> > When the network between the client and the server is saturated, TCP >> > sees packet loss, and throttles the connection. We can't do that >> > easily with UDP, not without losing UDP's advantages. >> >> Yes, you'd need to have the client monitor the rate at which it can >> receive and process packets and regularly ask the server to adjust >> the rate. > > Exactly. With the "udpfeed" command, the client could tell MPD how > many packets it has received since the last "udpfeed" command, and MPD > would then calculate the packet loss (it already knows how many > packets it has sent to that client). Based on that information, MPD > could throttle, or tell the client that it's not possible to send the > stream reliably.
I've studied some audio streaming problems and existent solutions, and I think that now, you are talking about RTCP over RTP :) Why not to use this protocol? It works over UDP and designed for delivering real-time audio (and video) over the Internet. Vasily ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
