xpra icon
Bug tracker and wiki

This bug tracker and wiki are being discontinued
please use https://github.com/Xpra-org/xpra instead.


Changes between Initial Version and Version 11 of Ticket #619


Ignore:
Timestamp:
01/25/18 05:18:46 (3 years ago)
Author:
Antoine Martin
Comment:

I'm seeing some weird behaviour with win32 clients trying to improve #999 and detecting late acks.

The network layer's source_has_more function may not be the right place to set and unset NODELAY because lots of small screen updates can take under a millisecond to compress, which is still slower than it takes the network layer to send them... Maybe we need to pass the screen update flush attribute down to the network layer too.

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #619

    • Property Priority changed from major to critical

  • Ticket #619 – Description

    initial v11  
    55It would be better to only enable {{{TCP_NODELAY}}} when aggregating packets is not helping: when we have no more data to send or when the output buffer is full. As per: [http://stackoverflow.com/questions/855544/is-there-a-way-to-flush-a-posix-socket Is there a way to flush a POSIX socket?] and this answer:
    66''What I do is enable Nagle, write as many bytes (using non-blocking I/O) as I can to the socket (i.e. until I run out of bytes to send, or the send() call returns EWOULDBLOCK, whichever comes first), and then disable Nagle again. This seems to work well (i.e. I get low latency AND full-size packets where possible) ''
     7
     8Good read: [https://eklitzke.org/the-caveats-of-tcp-nodelay The Caveats of TCP_NODELAY]