Skip to contentSkip to conversation

add VNC reverse connections

PATCH In review Eddie Kohler 4 participants 10 messages Jan 16, 2008 – Jan 17, 2008

lore
Share & tools
lore

Eddie Kohler

author
#0 lore raw

PATCH 1/1 add VNC reverse connections

Hi all,

This patch against current CVS adds VNC reverse connections, where the server connects actively to a waiting client, as in "-vnc rev:5500" or "-vnc rev:read.cs.ucla.edu:5500". This is quite useful if the user expects to run QEMU many times in succession (for example, is debugging a toy OS), and doesn't want to reopen a VNC client each time.

Eddie

Index: qemu-doc.texi
===================================================================
RCS file: /sources/qemu/qemu/qemu-doc.texi,v
retrieving revision 1.179

qemu-doc.texi +8 -2
diff -u -r1.179 qemu-doc.texi
@@ -429,10 +429,16 @@
 Connections will be allowed over UNIX domain sockets where @var{path} is the
 location of a unix socket to listen for connections on.
 
+@item @var{rev}:@var{interface}:@var{port}
+
+Makes a reverse connection to a VNC viewer listening on
+@var{interface} on port @var{port}. Optionally, @var{interface} can be
+omitted in which case QEMU will connect to @var{port} on the local machine.
+
 @item none
 
-VNC is initialized by not started. The monitor @code{change} command can be used
-to later start the VNC server.
+VNC is initialized but not started. The monitor @code{change} command
+can be used to later start the VNC server.
 
 @end table

Index: vnc.c
===================================================================
RCS file: /sources/qemu/qemu/vnc.c,v
retrieving revision 1.33

vnc.c +45 -14

101 lines not on this page · raw message

#1 lore raw
Quoted 4 lines · Eddie Kohler

Hi all,

This patch against current CVS adds VNC reverse connections, where the server connects actively to a waiting client, as in "-vnc rev:5500" or "-vnc rev:read.cs.ucla.edu:5500". This is quite useful if the user expects to run QEMU many times in succession (for example, is debugging a toy OS), and doesn't want to reopen a VNC client each time.

Neat!

Signature · 1 line
error compiling committee.c: too many arguments to function
#2 lore raw
In reply to Eddie Kohler
Quoted 7 lines · Eddie Kohler

Hi all,

This patch against current CVS adds VNC reverse connections, where the server connects actively to a waiting client, as in "-vnc rev:5500" or "-vnc rev:read.cs.ucla.edu:5500". This is quite useful if the user expects to run QEMU many times in succession (for example, is debugging a toy OS), and doesn't want to reopen a VNC client each time.

We already have the ability to pass multiple flags / options to the VNC driver as a post-fix to the host:port pair, so I'm not a fan of introducing a new option as a prefix. If using existing options syntax, it could look like:

-vnc :5500,rev
-vnc read.cs.ucla.edu:5500,rev

Regards,
Dan.

Signature · 4 lines
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|
#3 lore raw
Quoted 7 lines · Daniel P. Berrange
Quoted 4 lines · Eddie Kohler

Hi all,

This patch against current CVS adds VNC reverse connections, where the server connects actively to a waiting client, as in "-vnc rev:5500" or "-vnc rev:read.cs.ucla.edu:5500". This is quite useful if the user expects to run QEMU many times in succession (for example, is debugging a toy OS), and doesn't want to reopen a VNC client each time.

Quoted 8 lines

We already have the ability to pass multiple flags / options to the VNC driver as a post-fix to the host:port pair, so I'm not a fan of introducing a new option as a prefix. If using existing options syntax, it could look like:

-vnc :5500,rev
-vnc read.cs.ucla.edu:5500,rev

Yes, but please, let's spell out "reverse". This is a very nice patch to have as it's another way (than -daemonize) to reliably connect to the vnc server after launching a VM.

Regards,

Anthony Liguori

Quoted 3 lines

Regards,
Dan.

author
#4 lore raw
In reply to Daniel P. Berrange
Quoted 7 lines · Daniel P. Berrange

We already have the ability to pass multiple flags / options to the VNC driver as a post-fix to the host:port pair, so I'm not a fan of introducing a new option as a prefix. If using existing options syntax, it could look like:

-vnc :5500,rev
-vnc read.cs.ucla.edu:5500,rev

This doesn't feel like an option to me, though; rather a different means of connecting. Among other things, in "-vnc :0", the QEMU VNC server opens port 5900. But the client's listening port for reverse connections defaults to 5500. "-vnc :-400,rev" is clearly insane, but it seems strange for an option like ",rev" to change the meaning of the port field.

If you still disagree I'll produce a patch with ",reverse" as an option.

Eddie

#5 lore raw
Quoted 6 lines · Eddie Kohler
Quoted 5 lines · Daniel P. Berrange

We already have the ability to pass multiple flags / options to the VNC driver as a post-fix to the host:port pair, so I'm not a fan of introducing a new option as a prefix. If using existing options syntax, it could look like:

Quoted 6 lines
Quoted 2 lines

-vnc :5500,rev
-vnc read.cs.ucla.edu:5500,rev

This doesn't feel like an option to me, though; rather a different means of connecting. Among other things, in "-vnc :0", the QEMU VNC server opens port 5900. But the client's listening port for reverse connections defaults to 5500. "-vnc :-400,rev" is clearly insane, but it seems strange for an option like ",rev" to change the meaning of the port field.

If you still disagree I'll produce a patch with ",reverse" as an option.

I'm not a huge fan of the "option,mod,mod" syntax but Dan is right, it's what is used in QEMU. Consistency is often times better than sanity :-)

Regards,

Anthony Liguori

Quoted 3 lines

Eddie

#6 lore raw
In reply to Eddie Kohler
Quoted 6 lines · Eddie Kohler
Quoted 5 lines · Daniel P. Berrange

We already have the ability to pass multiple flags / options to the VNC driver as a post-fix to the host:port pair, so I'm not a fan of introducing a new option as a prefix. If using existing options syntax, it could look like:

Quoted 8 lines
Quoted 2 lines

-vnc :5500,rev
-vnc read.cs.ucla.edu:5500,rev

This doesn't feel like an option to me, though; rather a different means of connecting. Among other things, in "-vnc :0", the QEMU VNC server opens port 5900. But the client's listening port for reverse connections defaults to 5500. "-vnc :-400,rev" is clearly insane, but it seems strange for an option like ",rev" to change the meaning of the port field.

Yes that is a valid point. It is a little unfortunate we switched to using display num instead of port num for the current VNC code. Having a syntax which makes people use negative display nums for reverse connections would suck. So reluctantly I think your original proposal may actually be better.

Dan.

Signature · 4 lines
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|
#7 lore raw
Quoted 12 lines · Daniel P. Berrange
Quoted 10 lines · Eddie Kohler
Quoted 8 lines · Daniel P. Berrange

We already have the ability to pass multiple flags / options to the VNC driver as a post-fix to the host:port pair, so I'm not a fan of introducing a new option as a prefix. If using existing options syntax, it could look like:

-vnc :5500,rev
-vnc read.cs.ucla.edu:5500,rev

Quoted 8 lines
Quoted 2 lines

This doesn't feel like an option to me, though; rather a different means of connecting. Among other things, in "-vnc :0", the QEMU VNC server opens port 5900. But the client's listening port for reverse connections defaults to 5500. "-vnc :-400,rev" is clearly insane, but it seems strange for an option like ",rev" to change the meaning of the port field.

Yes that is a valid point. It is a little unfortunate we switched to using display num instead of port num for the current VNC code. Having a syntax which makes people use negative display nums for reverse connections would suck. So reluctantly I think your original proposal may actually be better.

Yet this is the syntax we use for normal connections. I don't see why the asymmetry is okay for reverse connections.

Regard,

Anthony Liguori

Quoted 2 lines

Dan.

author
#8 lore raw
Quoted 9 lines · Anthony Liguori
Quoted 7 lines
Quoted 2 lines

This doesn't feel like an option to me, though; rather a different means of connecting. Among other things, in "-vnc :0", the QEMU VNC server opens port 5900. But the client's listening port for reverse connections defaults to 5500. "-vnc :-400,rev" is clearly insane, but it seems strange for an option like ",rev" to change the meaning of the port field.

Yes that is a valid point. It is a little unfortunate we switched to using display num instead of port num for the current VNC code. Having a syntax which makes people use negative display nums for reverse connections would suck. So reluctantly I think your original proposal may actually be better.

Yet this is the syntax we use for normal connections. I don't see why the asymmetry is okay for reverse connections.

Because reverse connections feel very different from normal connections, use ports instead of "display numbers", etc.?

Here's what the manual would look like for the "rev:" syntax.

interface:d
TCP connections will only be allowed from interface on display d. By convention the TCP port is 5900+d. Optionally, interface can be omitted in which case the server will bind to all interfaces.
...
rev:[address:]port
Connects to a VNC client listening at address:port. Optionally, address can be omitted in which case the server connects to localhost:port.

Here's what the manual would look like for the ",reverse" syntax.

Valid syntax for the display is

interface:d
TCP connections will only be allowed from interface on display d. By convention the TCP port is 5900+d. Optionally, interface can be omitted in which case the server will bind to all interfaces.
...
reverse
QEMU will connect to a listening VNC client, rather than waiting for a client connection. If the connection has type "interface:d", then "interface" is the client address; if omitted, localhost is used. The display number "d" is added to 5900 to determine the port, so negative numbers might be necessary to connect to default client ports.

Or are you thinking

For reverse connections, the display number "d" is added to 5500 to determine the port.

in which case the interface:d definition is incorrect?

I'm not trying to make this look ugly on purpose. The prefix syntax seems friendlier.

Eddie

author
#9 lore raw
In reply to Anthony Liguori

Well, attached is a patch with ",reverse" syntax, anyway; hopefully one of these syntaxes is OK!

Eddie

Quoted 5 lines · Anthony Liguori
Quoted 4 lines · Daniel P. Berrange
Quoted 2 lines · Eddie Kohler

Daniel P. Berrange wrote:

Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines

We already have the ability to pass multiple flags / options to the VNC driver as a post-fix to the host:port pair, so I'm not a fan of introducing a new option as a prefix. If using existing options syntax, it could look like:

-vnc :5500,rev
-vnc read.cs.ucla.edu:5500,rev

Index: qemu-doc.texi
===================================================================
RCS file: /sources/qemu/qemu/qemu-doc.texi,v
retrieving revision 1.179

qemu-doc.texi +14 -7
diff -u -r1.179 qemu-doc.texi
@@ -418,21 +418,21 @@
 
 @table @code
 
-@item @var{interface}:@var{d}
+@item @var{host}:@var{d}
 
-TCP connections will only be allowed from @var{interface} on display @var{d}.
-By convention the TCP port is 5900+@var{d}. Optionally, @var{interface} can
-be omitted in which case the server will bind to all interfaces.
+TCP connections will only be allowed from @var{host} on display @var{d}.
+By convention the TCP port is 5900+@var{d}. Optionally, @var{host} can
+be omitted in which case the server will accept connections from any host.
 
-@item @var{unix}:@var{path}
+@item @code{unix}:@var{path}
 
 Connections will be allowed over UNIX domain sockets where @var{path} is the
 location of a unix socket to listen for connections on.
 
 @item none
 
-VNC is initialized by not started. The monitor @code{change} command can be used
-to later start the VNC server.
+VNC is initialized but not started. The monitor @code{change} command
+can be used to later start the VNC server.
 
 @end table
 

@@ -441,6 +441,13 @@
 
 @table @code
 
+@item reverse
+
+Connect to a listening VNC client via a ``reverse'' connection. The
+client is specified by the @var{display}. For reverse network
+connections (@var{host}:@var{d},@code{reverse}), the @var{d} argument
+is a TCP port number, not a display number.
+
 @item password
 
 Require that password based authentication is used for client connections.

Index: vnc.c
===================================================================
RCS file: /sources/qemu/qemu/vnc.c,v
retrieving revision 1.33

vnc.c +40 -14

96 lines not on this page · raw message