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

[Romanovsky Vladislav]

> 
> ----- Original Message -----
> > I read the blueprint and the conversation with Daniel.
> > To be honest, I'm not that big HTTP fan, so probably I'm missing something.
> > 
> > If I were to write a userspace proxy that supports HTTP Connect, I would
> > just
> > create a
> > new request handler to handle the CONNECT, get the source host:port and the
> > destination host:port and
> > connect their sockets, which will create additional connections for all the
> > channels.
> 
> That's what I wrote, no?
> > 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.

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

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

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

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

> 
> > 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()
> 
> > 
> > Thanks,
> > Vladik
> > 
> > ----- Original Message -----
> > > From: "Marc-André Lureau" <mlureau at redhat.com>
> > > To: "Romanovsky Vladislav" <vromanso at redhat.com>
> > > Cc: "Dennis Chen" <atticcat at gmail.com>,
> > > spice-devel at lists.freedesktop.org,
> > > "Christophe Fergeau"
> > > <cfergeau at redhat.com>, "Artom Lifshitz" <alifshit at redhat.com>
> > > Sent: Thursday, 23 April, 2015 9:14:21 AM
> > > Subject: Re: [Spice-devel] are there any new spice protocol document?
> > > 
> > > Hi
> > > 
> > > ----- Original Message -----
> > > > A while ago I've started to work on a similar proxy for Spice as part
> > > > of
> > > > the
> > > > Openstack Nova project. However, It should fine to use it without
> > > > openstack.
> > > > 
> > > > So far, there are two working versions, one for userspace and another
> > > > is
> > > > a
> > > > transparent proxy.
> > > > However, we are now focusing on the transparent one, as the userspace
> > > > one
> > > > was
> > > > slow..
> > > > 
> > > > The idea is to setup forwarding rules (iptables) between the client and
> > > > the
> > > > spice
> > > > port on a proxy host. When the client will request a spice console, a
> > > > new
> > > > port will be opened
> > > > on the proxy host, for which forwarding rules will be setup to the
> > > > destination.
> > > > The proxy will respond with a port number to which the native client
> > > > should
> > > > connect to.
> > > > It will also monitor the rules and will remove those which are no
> > > > longer
> > > > connected.
> > > > 
> > > > At the moment we have a working code, but it's far from being in a good
> > > > shape. (As it was a side project for us so far)
> > > > There are 2 people involved and each has some part of the code locally.
> > > > 
> > > > In the coming days we should be able to consolidate everything in a
> > > > repo
> > > > below, however, as far this served
> > > > us just for hacking.
> > > > https://github.com/vladikr/spicetcpproxy
> > > > 
> > > > We are now in a process of writing a proper blueprint for Nova.
> > > > Thoughts
> > > > are
> > > > more than welcome :)
> > > 
> > > How does it compare to:
> > > https://blueprints.launchpad.net/nova/+spec/spice-http-proxy
> > > 
> > > To me it sounds simpler, less limited and more secure to have a single
> > > proxy
> > > port than having to fiddle with forwarding rules.
> > > 
> > > cheers
> > >
> > 
>