XDMCP over SSH - a better idea (hopefully)
wharms at bfs.de
Tue Aug 4 06:09:51 PDT 2009
Vic Lee schrieb:
> Sorry I sent this email to xorg-devel but I realized that this should be
> a feature discussion, not yet a development discussion... So I resend it
> Recently I want to implement XDMCP over SSH feature when doing my
> project. I've done some research and understand that "XDMCP uses UDP
> that natively cannot be tunnelled over SSH", however there's a
> well-known workaound:
> LOCAL$ ssh -X REMOTE Xephyr :1 -query localhost
> which query XDMCP in a remote Xephyr, then to tunnel the Xephyr window
> using X11 forwarding. However this is not working good enough for me
> since (1) I don't want to ask users to install Xnest or Xephyr on SSH
> server (2) Somehow the tunnelled Xephyr window won't recognize -parent
> argument to embed into my app - it always create a top-level window;
> well, this could be another bug but I don't want to waste my time
> investigating on this, since now I came up with a better solution.
> I would like to implement a new binary, let's temporarily call it
> "xdmcp-bin". It will fully implement the XDMCP protocol and talks to any
> Display Manager; however, instead of creating a new X server like Xephyr
> or Xnest does, it simply ask the Display Manager to connect to an
> existing one (usually this is the X server that $DISPLAY is pointing to
> - like any other X clients).
> So here comes the real thing. :) A typical XDMCP over SSH senario would
> LOCAL$ Xephyr :1 (or even X :1, whatever that creates a new X server)
> LOCAL$ export DISPLAY=:1
> LOCAL$ ssh -X REMOTE xdmcp-bin -query localhost
> What happen in the third line is that, "xdmcp-bin" runs on REMOTE, query
> its Display Manager to create a new session and connect to "xdmcp-bin"'s
> DISPLAY environment, which is a X11 tunnel that connects back to :1 at
> LOCAL. You know what should happen next: we tunnel XDMCP session.
> I am totally new to X.org development. I would like to get your comments
> before I get started with this new feature.
It sounds a bit like nx or neatx, are you aware of this solutions ?
More information about the xorg