On (Fri) Jan 08 2010 [01:12:31], Jamie Lokier wrote:
> Amit Shah wrote:
> > Guests send us one buffer at a time. Current guests send buffers sized
> > 4K bytes. If guest userspace applications sent out > 4K bytes in one
> > write() syscall, the write request actually sends out multiple buffers,
> > each of 4K in size.
> >
> > This usually isn't a problem but for some apps, like VNC, the entire
> > data has to be sent in one go to make copy/paste work fine. So if an app
> > on the guest sends out guest clipboard contents, it has to be sent to
> > the vnc server in one go as the guest app sent it.
> >
> > For this to be done, we need the guest to send us START and END markers
> > for each write request so that we can find out complete buffers and send
> > them off to ports.
>
> That looks very dubious. TCP/IP doesn't maintain write boundaries;
> neither do pipes, unix domain sockets, pseudo-terminals, and almost
> every other modern byte-oriented transport.
>
> So how does VNC transmit the clipboard over TCP/IP to a VNC client,
> without those boundaries, and why is it different with virtserialport?
TCP does this in its stack: it waits for the number of bytes written to
be received and then notifies userspace of data availibility.
In this case, consider the case where the guest writes 10k of data. The
guest gives us those 10k in 3 chunks: the first containing 4k (- header
size), the 2nd containing the next 4k (- header size) and the 3rd chunk
the remaining data.
I want to flush out this data only when I get all 10k.
Amit
