https://www.hardening-consulting.com/enTue, 18 Feb 2025 22:51:03 GMTNikola (getnikola.com)http://blogs.law.harvard.edu/tech/rsshttps://www.hardening-consulting.com/en/posts/20140522rock-around-freerdp.htmlDavid FORT<div><p><img class="alignright" alt="FreeRdp" src="https://www.hardening-consulting.com/images/FreeRDP-small.png"></p> <p>These days, I have been working on having writes being non-blocking in <a href="http://www.freerdp.com/">FreeRdp</a>. That makes me walk through most of the low level component of FreeRdp, so let me share things I have collected during this code walk. </p> <h2>Setting write calls non-blocking</h2> <p>The actual code is non-blocking for read: it handles a <em>EAGAIN</em> or <em>EWOULDBLOCK</em> for a read() call. But for write calls, it will actively wait until all data have been sent. For the FreeRDP client you almost never hit the case where write calls gets blocked, because most of the traffic is from the server to the client (sending screen updates). You can hit it anyway when using the channels: Disk Redirection (pushing a file to the server) or audio in (microphone exported to the server).</p> <p>But when you're in FreeRDS acting as a RDP server, blocking writes is very common. Just try to see a fullscreen video through a slow WIFI connection.</p> <p><a href="https://www.hardening-consulting.com/en/posts/20140522rock-around-freerdp.html">Read more…</a> (4 min remaining to read)</p></div>Cevent drivenfreerdpnon blockingtsghttps://www.hardening-consulting.com/en/posts/20140522rock-around-freerdp.htmlThu, 22 May 2014 17:03:19 GMT