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

[Gerd Hoffmann <kraxel@redhat.com>]

On 07/01/09 23:32, Anthony Liguori wrote:
> 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.

I didn't say it is easy ;)

But I want to make sure we don't miss the big picture when we start 
multiplexing for vnc, so others can join the party.

> [ flow control issues ]

Tricky indeed.  I think Dan's current patches don't care about flow 
control at all.

> 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.

Dan's patches can do mirroring only.

I *think* one could build a tcp backend based on Dan's patches which can 
handle multiple connections at the same time.  It would basically do the 
same vnc data streams do:  Listen for connects, when a new connection 
comes in create a new CharCaptureState instance and link it up.  When 
the connection drops teardown.

> In this model, I still don't see having two different back-ends
> connected to a single front-end.

The frontend shouldn't have to care at all about who owns the 
CharCaptureState instances it feeds.

> I don't know if I agree there's a whole
> lot of value in that

Having a file backend writing logs and some other backend for 
interactive work is a very reasonable thing IMHO.

cheers,
   Gerd