Dnia Saturday 08 of March 2008, napisałeś: > 2008/3/8 Tomasz Grobelny <tomasz@xxxxxxxxxxxxxxxxxxxxxxx>: > > The deadline is not that easy to determine due to client side buffering. > > At least that would require cooperation on receiving side. For now I just > > assume that some packets are simply more important than others. That is > > they convey more information to the one who is watching. When streaming > > football match you are probably less interested in voice comments, music > > and applause and more about "where is the ball?" (video more important). > > But when watching the news usually audio is much more important than the > > object on video that you've already seen thousands of times. > > You can track the rtt and also mark the expiry time and do the maths. > Again check my papers... I think we don't understand each other well here. My point is that no matter what the kernel does it cannot always know whether packet will be late or not. That is because it would need feedback from client how much of the stream is buffered. Suppose that RTT is 10ms but the client code buffered 15 seconds of transmission. If the packet was waiting in DCCP send queue for 5 seconds should we send it or discard? Without feedback from the player we cannot tell. In some applications it is possible to assume some sensible defaults or negotiate delay. But that is not a priority for me for now. But of course the design should allow specifying deadline. -- Regards, Tomasz Grobelny -- To unsubscribe from this list: send the line "unsubscribe dccp" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
