Good to see my suggestion didn't fall on deaf ears.
----- Original Message ----- > From: "Zhou Zheng Sheng" <zhshz...@linux.vnet.ibm.com> > To: "Saggi Mizrahi" <smizr...@redhat.com> > Cc: "VDSM Project Development" <vdsm-devel@lists.fedorahosted.org>, "Adam > Litke" <a...@us.ibm.com>, "Ayal Baron" > <aba...@redhat.com>, "Barak Azulay" <bazu...@redhat.com>, "Dan Kenigsberg" > <dan...@redhat.com> > Sent: Tuesday, January 15, 2013 4:30:03 AM > Subject: Re: remote serial console via HTTP streaming handler > > > on 01/08/2013 04:10, Saggi Mizrahi wrote: > > The solution is somewhat elegant (and only ~150 LOC). > > That being said I still have some 2 major problems with it: > > The simpler one is that it uses HTTP in a very non-standard manner, > > this > > can be easily solved by using websockets[2]. This is very close > > to what the patch already does and will make it follow some sort of > > a > > standard. This will also enable console on the Web UI to expose > > this on > > newer browsers. > Using WebSocket is a good idea. I have a look at its standard > (http://tools.ietf.org/html/rfc6455). The framing and the security > model > is not trivial to implement (compared to that existing patch which > enables HTTP to forward PTY octet stream in full duplex). Luckily > there > are some open-source WebSocket implementations. > > The second and the real reason I didn't put it just as a comment on > > the > > patch is that that using HTTP and POST %PATH to have only one > > listening > > socket for all VMs is completely different from the way we do VNC > > or SPICE. > > This means it kind of bypasses ticketing and any other mechanism we > > want > > to put on VM interfaces. > I think HTTP digest authentication may be implemented in the current > PTY > forwarding patch to enable ticketing. > > > The thing is, I really like it. I was suggesting that we extend > > this idiom > > to use for SPICE and VNC and tunneling it through a single > > http\websocket > > listener. So instead of making this work with the current methods > > make this > > the way to go. > > > > Using headers like: > > GET /VM/<VM_ID>/control HTTP/1.1 > > Host: server.example.com > > Upgrade: websocket > > Ticket: <TICKET> > > Connection: Upgrade > > Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw== > > Sec-WebSocket-Protocol: [pty, vnc, spice] > > Sec-WebSocket-Version: 13 > > Origin:http://example.com > In the Spice official site, I see a demo project spice-html5 uses a > WebSocket-Spice gateway to get the data. The Spice is tunneled in > WebSocket between the client and the gateway. This is good for > javascript running in browsers. If VDSM support tunneling the PTY, > VNC > and Spice in WebSocket, writing a viewers in browsers maybe easier. > > A WebSocket proxy can also be implemented to support migration with > PTY. > The PTY data stream is VDSM<=>proxy<=>client. When migrating, VDSM > sends > this event to proxy via AMQP, then shuts down the current WebSocket > connection. The proxy can keep the connection with the client. After > migration, another VDSM sends this event to proxy via AMQP, then the > proxy establish the WebSocket connection with VDSM and continue the > forwarding. > > We can also connect two guests' serial port by forwarding the data > stream via this proxy back and forth with support for migration as > explained above. Furthermore, the proxy can exposes the data stream > in > various plug-in protocols such as SOCKS, HTTP, SSH, telnet to various > client. For example the proxy provide SOCKS support, then we can use > socat as a SOCKS client to connect to guest serial port and pipe the > data to FD 0 and 1 to a process running in the host. Also, I don't think it's such a problem to have the client change "servers" usually even if websockets are invovled. It just means that client needs to be aware of the possibility of an extra layer. > > -- > Thanks and best regards! > > Zhou Zheng Sheng / 周征晟 > E-mail:zhshz...@linux.vnet.ibm.com > Telephone: 86-10-82454397 > > _______________________________________________ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel