| Message ID | 1409649717-17004-1-git-send-email-pl@kamp.de |
|---|---|
| State | New |
| Headers | show |
On 2 September 2014 10:21, Peter Lieven <pl@kamp.de> wrote: > we currently have the Nagle algorithm enabled for all outgoing VNC updates. > This may delay sensitive updates as mouse movements or typing in the console. > As we currently prepare all data in a buffer and then send as much as we can > this should not cause big trouble. Well established VNC servers like TightVNC > set TCP_NODELAY as well. > A regular framebuffer update request generates exactly one framebuffer update > which should be pushed out as fast as possible. > > Signed-off-by: Peter Lieven <pl@kamp.de> > --- > ui/vnc.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/ui/vnc.c b/ui/vnc.c > index 1bc1ae0..b12d0ea 100644 > --- a/ui/vnc.c > +++ b/ui/vnc.c > @@ -2885,6 +2885,10 @@ static void vnc_listen_read(void *opaque, bool websocket) > } > > if (csock != -1) { > +#ifdef TCP_NODELAY > + int flag = 1; > + setsockopt(csock, IPPROTO_TCP, TCP_NODELAY, (char *) &flag, sizeof(int)); > +#endif > vnc_connect(vs, csock, false, websocket); Why not just call socket_set_nodelay() ? thanks -- PMM
On 02.09.2014 11:36, Peter Maydell wrote: > On 2 September 2014 10:21, Peter Lieven <pl@kamp.de> wrote: >> we currently have the Nagle algorithm enabled for all outgoing VNC updates. >> This may delay sensitive updates as mouse movements or typing in the console. >> As we currently prepare all data in a buffer and then send as much as we can >> this should not cause big trouble. Well established VNC servers like TightVNC >> set TCP_NODELAY as well. >> A regular framebuffer update request generates exactly one framebuffer update >> which should be pushed out as fast as possible. >> >> Signed-off-by: Peter Lieven <pl@kamp.de> >> --- >> ui/vnc.c | 4 ++++ >> 1 file changed, 4 insertions(+) >> >> diff --git a/ui/vnc.c b/ui/vnc.c >> index 1bc1ae0..b12d0ea 100644 >> --- a/ui/vnc.c >> +++ b/ui/vnc.c >> @@ -2885,6 +2885,10 @@ static void vnc_listen_read(void *opaque, bool websocket) >> } >> >> if (csock != -1) { >> +#ifdef TCP_NODELAY >> + int flag = 1; >> + setsockopt(csock, IPPROTO_TCP, TCP_NODELAY, (char *) &flag, sizeof(int)); >> +#endif >> vnc_connect(vs, csock, false, websocket); > Why not just call socket_set_nodelay() ? I was not aware of that helper function. Thanks for the pointer. Peter > > thanks > -- PMM
diff --git a/ui/vnc.c b/ui/vnc.c index 1bc1ae0..b12d0ea 100644 --- a/ui/vnc.c +++ b/ui/vnc.c @@ -2885,6 +2885,10 @@ static void vnc_listen_read(void *opaque, bool websocket) } if (csock != -1) { +#ifdef TCP_NODELAY + int flag = 1; + setsockopt(csock, IPPROTO_TCP, TCP_NODELAY, (char *) &flag, sizeof(int)); +#endif vnc_connect(vs, csock, false, websocket); } }
we currently have the Nagle algorithm enabled for all outgoing VNC updates. This may delay sensitive updates as mouse movements or typing in the console. As we currently prepare all data in a buffer and then send as much as we can this should not cause big trouble. Well established VNC servers like TightVNC set TCP_NODELAY as well. A regular framebuffer update request generates exactly one framebuffer update which should be pushed out as fast as possible. Signed-off-by: Peter Lieven <pl@kamp.de> --- ui/vnc.c | 4 ++++ 1 file changed, 4 insertions(+)