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. _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel