<div dir="ltr">I heard that iptv uses udp multicast, so I thought that performance might be better if we use udp for video streaming. We can ignore missing and out of order frames. Does it make sense?<div><br></div><div>I understand that we need tcp channels for all others such as input and audio channels.</div></div><div class="gmail_extra"><br><div class="gmail_quote">2016-02-02 23:03 GMT+09:00 Gerd Hoffmann <span dir="ltr"><<a href="mailto:kraxel@redhat.com" target="_blank">kraxel@redhat.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Di, 2016-02-02 at 10:24 +0100, Christophe Fergeau wrote:<br>
> Hey,<br>
><br>
> On Tue, Feb 02, 2016 at 06:10:28PM +0900, Sunny Shin wrote:<br>
> > I have a few questions about udp version of spice protocol.<br>
> ><br>
> > Is there a plan to support udp in spice protocol?<br>
> ><br>
> > If we support udp, what do we need to implement?<br>
> > Is it enough to change tcp channels to udp ones?<br>
><br>
> Maybe that would be enough, maybe more changes would be needed, I cannot<br>
> exactly tell you. My main worries with UDP would be packet drops as<br>
> there is nothing guaranteeing you that the packets you send will arrive<br>
> at all to the other end of the connexion.<br>
<br>
</span>That is exactly the problem.  Packets may get dropped.  Packets may also<br>
arrive out-of-order.  So using UDP is fine if loosing data is fine[1].<br>
<br>
For spice this is largely not ok.  Maybe for the audio channel, if you<br>
are willing to accept sound dropouts in case of packet loss.  Loosing<br>
display channel messages will lead to rendering gliches due to missing<br>
data and render tree inconsistencies.  Not cool.  Loosing input channel<br>
messages may mess up the keyboard state such as keys being stuck due do<br>
keyup messages being lost.  That is even less funny.  Webdav file<br>
sharing corrupting your files?  Have the backups ready!<br>
<br>
cheers,<br>
  Gerd<br>
<br>
[1] In theory one could implement some scheme to track packet<br>
    status, resend lost packets etc to fix this.  In practice<br>
    the better answer to that is "use TCP" which does exactly<br>
    that.  And keep in mind that the TCP algorithms in todays<br>
    OS kernels are the result of decades of network protocol<br>
    research.  Coming up with an implementation which matches<br>
    TCP in performance certainly is not trivial.<br>
<br>
</blockquote></div><br></div>