Re: [Qemu-devel] [PATCH 0/2] Tunnel character device data over VNC (v1)

[Anthony Liguori <anthony@codemonkey.ws>]

Gerd Hoffmann wrote:

> With multiple connections and multiplexing:  You'll just connect, type 
> a few commands, disconnect, done.  You'll even see what you have done 
> when you come back to the office the next day.
>
> Also note that the vnc server accepts input from multiple clients as 
> well, which can lead to simliar problems.  Nobody wants to kill 
> support for multiple clients just because of that, because in practice 
> it isn't a issue.

I don't disagree with your use-case.  What I'm pointing out, is that we 
need to do some major surgery to get there.

The current chardev protocol has no real notion of flow control and 
assumes a static bidirectional channel between the front-end and 
back-end.  Flow control policy is inconsistent and those decisions are 
made in the back-end (i.e. tcp:).

We really need to push flow-control to be a proper part of the protocol 
though so that the front-end can participate.  For instance, 
virtio-console/serial is fully capable of implementing flow control.  
Punting buffering policy to the guest is IMHO the best possible solution 
to the general problem.

Having multiple connections within a chardev really also needs to be 
part of the monitor protocol because it's fundamental to flow-control.  
We want the front-end to have enough information to know how many 
clients are connected and which ones are ready to receive.

When dealing with a single I/O source, it should be front-end policy to 
determine what to do.  Certainly, there are some front-ends (like the 
monitor) that can support multiple I/O sources.  Another example is the 
VNC server which really should be using chardevs.

I agree that mirroring is a pretty reasonable policy to map a single I/O 
source to multiple clients for some devices.  That should be a front-end 
decision though.

In this model, I still don't see having two different back-ends 
connected to a single front-end.  I don't know if I agree there's a 
whole lot of value in that although the implementation is straight 
forward (a special back-end that unifies multiple front-ends as sessions).

Regards,

Anthony Liguori