[pve-devel] [PATCH 1/2] add spiceproxy api2

[Alexandre DERUMIER]

>>BTW, the current code forks 5 socat processes per spice - can we avoid that (do not fork)? 

spice client need multiple tcp connections, 1 by channel (6 channels max). so, we can't avoid the socat fork.


http://spice-space.org/docs/spice_for_newbies.pdf

"
The client and server communicate via channels. Each channel type is dedicated to a specific type
of data. Each channel uses a dedicated TCP socket, and it can be secured (using SSL) or unsecured.
On the client side each channel has a dedicated thread, so different QoS can be given to each one by
differentiating their thread priority.

RedClient
serves as the main channel. It owns all the other instantiated channels and controls them
(creating channels using their factory, connecting, disconnecting, etc.), and handles control,
configuration and migration (using the Migrate class). 

The available channels are:
o
Main - implemented by RedClient (see above).
o
DisplayChannel - handles
graphic commands, images and video streams
.
o
InputsChannel -
keyboard and mouse inputs
.
o
CursorChannel -
pointer device position, visibility and cursor shape
.
o
PlaybackChannel -
audio received from the server to be played by the client
.
o
RecordChannel -
audio capture
d
on the client side
.
"





----- Mail original ----- 

De: "Dietmar Maurer" <dietmar at proxmox.com> 
À: "Alexandre DERUMIER" <aderumier at odiso.com> 
Cc: pve-devel at pve.proxmox.com 
Envoyé: Mardi 25 Juin 2013 18:02:20 
Objet: RE: [pve-devel] [PATCH 1/2] add spiceproxy api2 

> > I think we can add http connect proxy later, maybe when https will be 
> > supported. 
> 
> >>sure, but what for? We can do everything without that? 
> 
> with proxy, we just need 1 port open. (could be great for enterprise users with 
> firewall restrictions, network admin don't like to open big ranges of port ;) 
> 
> But this can wait, it's just an improvement. 

Well, we already have the requirement to open port 5900-6000 for VNC. 
But yes, that would be an advantage. 

Second, I would be possible to check the ticket earlier by the proxy. The current code 
proxies everything to kvm (not good). 

BTW, the current code forks 5 socat processes per spice - can we avoid that (do not fork)?