> > ----- 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@xxxxxxxxxx> > > > To: "Romanovsky Vladislav" <vromanso@xxxxxxxxxx> > > > Cc: "Dennis Chen" <atticcat@xxxxxxxxx>, > > > spice-devel@xxxxxxxxxxxxxxxxxxxxx, > > > "Christophe Fergeau" > > > <cfergeau@xxxxxxxxxx>, "Artom Lifshitz" <alifshit@xxxxxxxxxx> > > > Sent: Thursday, 23 April, 2015 9:14:21 AM > > > Subject: Re: 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 > > > > > > _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel