[Spice-devel] are there any new spice protocol document?

[Marc-André Lureau]

Hi

----- Original Message -----
> > > However, this is still a userspace proxy. For every connection we will
> > > have
> > > 4
> > > threads/process(websockets),
> > > that would loop through select() all the time..
> > 
> > Hmm, I am not sure this is any valid argument for performance here (having
> > multiple threads or processes isn't usually an issue, nor is using select
> > for io). What websocket?
> For me it was. I've seen that there is a huge performance degradation when it
> was
> implemented in userspace. It was worse with more VMs added. Not talking about
> Video at all that was terrible, keyboard/mouse was even slow.
> That's why I went ahead with the transparent one.

really? that sounds very strange, are you sure you were using non-blocking io?

> You can just use the websockets library in python with your request handler.
> (https://pypi.python.org/pypi/websockets)

It's not websocket. The native client doesn't talk websocket.

> > My simple HTTP proxy (took me a few hours to write) is thread base:
> > https://review.openstack.org/#/c/38974/2/nova/console/spicehttpproxy.py
> > 
> > (note: it does generate a vv virt-viewer file and check the token is valid
> > on
> > CONNECT etc, yet under 140 lines..)
> > 
> > I didn't focus on performance, but there are ways to improve it I believe
> > (using splice for ex). Fortunately, this isn't yet an issue.
> 
> IIRC, splice doesn't work well with TCP sockets, you will need a pipe and
> it will make things unimaginably slow.

I would really like to understand what is slow here :) Spice uses a ridiculous
amount of bandwidth compared to what CPU can handle.

> > > For Openstack I think it will be painful, considering the attempts to
> > > handle
> > > thousands of VMs.
> > 
> > Well, they use the websocket proxy for vnc, which is arguably much heavier
> > than a simple http connect proxy.
> It's all about expectations.. no one expects much from VNC..

They have comparable bandwidth usage, depending on use case, it's still in
the same range.

> > > Transparent proxy would just forward the packets to the relevant hosts,
> > > without copying it between sockets in userspace,
> > > creating a bottleneck on the proxy server and in fact slowing down Spice.
> > > IIRC, Openstack Neurton is doing something similar, regarding forwarding.
> > 
> > Ah ok, and for what protocol?
> Not sure exactly, I've seen it in their code. :)
> > 
> > > In order to address the security issues, we can password protect the
> > > spice
> > > connection and use ticketing, like Ovirt project does..
> > > Which security aspects are concerning you?
> > 
> > Fiddling with forwarding rules
> That's should be relatively easy and already implemented.

It's not about being easy to write, it's about how easy it would be to use maliciously.

> > 
> > > Also, why do you think this approach is limited?
> > 
> > The number of ports you can open is limited
> Right, but the userspace one will have the same problem, won't it?
> There will be a new port open every time you will accept()

No new ports, but new fds.