Hi, Thanks for you comments.
Actually I am already quite familar with how NX works, and supporting NX is one of my future goals in my project grdc. Although NX is based on X + SSH, to me it's like a new protocol. It has it's own SSH session commands, X compression algorithms, etc. And it does not use XDMCP at all. But right now I am working on XDMCP. The good thing is that XDMCP is a standard component of X.org server, and still lots of people out there using it. The only thing that is really necessary is security - which I want to put in a quick enhancement inside X.org; not a workaround. And what I want to add is quite simple - just a binary that implements the XDMCP protocol and forward request to an existing X server, like a proxy program. Thanks, Vic On Tue, 2009-08-04 at 15:09 +0200, walter harms wrote: > > Vic Lee schrieb: > > Hi, > > > > 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 > > here. > > > > 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 > > be: > > > > 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 ? > > re, > wh > _______________________________________________ xorg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xorg
