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

[Marc-André Lureau]

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

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.

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

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

> 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

> Also, why do you think this approach is limited?

The number of ports you can open is limited

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