#107 Patch to add API for Virtual Channels

Simon Guerrero

This patch makes the virtual channel capability in
rdesktop visible to third parties, so that applications
which extend RDP using the virtual channels can "plug
in" to rdesktop by supplying a shared object.

A new variant of the "-r" option has been implemented,
-r soname.so:opt1:opt2:opt3...optn

where soname.so is the name (fully qualified if need
be) of the third party shared object. opt1 to optn are
optional arguments which will be passed to the shared
object if needed.

The API is implemented as follows:

* All third party shared object must implement two
named functions, rdesktop_init and rdesktop_cleanup.

* A new function called "init_external_vchannel" has
been added to channels.c. Whenever a shared object is
specified in the parameters, a handle is opened using
dlopen and this handle is added to an array for use
later. The rdesktop_init function is located and
called, passing in the addresses of the virtual channel
functions in rdesktop (channel_register, channel_init,
channel_send) and any arguments which were passed in on
the command line. The third party app can then use
these functions to send and receive data on virtual
channels, just like sound, cut and paste etc. The
rdesktop_cleanup address is then located and stored.

* At the end of the RDP session, rdesktop calls the
rdesktop_cleanup function for each third party shared


1 2 3 > >> (Page 1 of 3)
  • Simon Guerrero
    Simon Guerrero

    Patch to add virtual channel API

  • Simon Guerrero
    Simon Guerrero

    • summary: Virtual Channel API --> Patch to add API for Virtual Channels
  • Peter Åstrand
    Peter Åstrand

    • status: open --> closed-rejected
  • Peter Åstrand
    Peter Åstrand

    Logged In: YES

    A mechanism like this one has been discussed and also
    rejected before. Using plugins this way violates the GPL,
    unless the plugin is also GPL (or compatible). In that case,
    it's better to submit it for inclusion into the rdesktop

  • Alon Bar-Lev
    Alon Bar-Lev

    Logged In: YES


    Just wanted to note that the same issue exists with kernel
    models... And we have modules.

    And why bother... One can get the source of rdesktop and add
    whatever he wishes and violate GPL.

    This is not a good reason why a plugin interface should not
    be added.

    Best Regards,
    Alon Bar-Lev.

  • Peter Åstrand
    Peter Åstrand

    Logged In: YES

    >Just wanted to note that the same issue exists with kernel
    >models... And we have modules.

    But not without problems. For example, the kernel has a
    "tainted" mechanism, which can show if you have loaded
    binary-only modules. This patch contains no such support, right?

    >This is not a good reason why a plugin interface should not
    >be added.

    The question should rather be: "Why *should* a plugin
    interface be added?". Why isn't it acceptible to contribute
    the plugins you are developing to the rdesktop project?

  • Pierre Ossman
    Pierre Ossman

    Logged In: YES

    The comparison to kernel modules is flawed. Kernel modules
    are there to reduce the footprint of the kernel, not to
    allow out-of-tree drivers. Like this project, the Linux
    project does not cater to external add-ons (which is why
    the kernel doesn't have a stable module API). It adds
    complexity and reduces flexibility, so you need to present a
    strong case for setting up such a system.

  • Alon Bar-Lev
    Alon Bar-Lev

    Logged In: YES

    Well... I thought the kernel is a good known example... But
    there are many more GPLed projects with plugins... But it is
    your call. I think that virtual channel is a good example
    where such interface is required... But I understand your
    position to merge all into your project.

  • Simon Guerrero
    Simon Guerrero

    Logged In: YES


    I submitted this patch after long discussions with Matt
    Chapman, who suggested this means of exposing the virtual
    channel functionality.

    While I understand the suggestion this is a way of getting
    around the GPL, and everyone who wants to add something to
    rdesktop ought to make their code open source too, I don't
    agree. The ability to expose the virtual channel
    functionality is a fundamental component of Citrix and RDP
    on Windows, for example, and as a result there are multiple
    commercial users of Citrix (and RDP) who have produced
    commercial offerings to add functionality which isn't
    natively available in those technologies as they stand.

    While I would agree wholeheartedly that new technology
    developed purely to extend rdesktop should naturally be
    GPL'd, I would point out that there are a huge number of
    commercial Windows products for RDP virtual channels which
    simply aren't being implemented on Linux because they don't
    want to go ahead and GPL all their code. And because they
    don't make it available for Linux, customers go with
    Windows solutions. Or providers of the technology go ahead
    and violate the GPL - which is what some of my commercial
    clients will just go and do if they don't have this. I know
    because that's what they wanted to do first.

    I would be glad to discuss technical issues with this
    solution to make it technically "good", as I really think
    rdesktop is missing this. But I think rejecting it out of
    hand because it might encourage people to create non-GPL
    virtual channel solutions is taking a pretty narrow view,


  • Logged In: YES

    Since rdesktop is licensed under the GPL, rather than under
    the LGPL, it would be illegal to make rdesktop link, even in
    runtime, with a non-free virtual channel shared library.
    rdesktop could be relicensed but since there wasn't any
    copyright assignment process, the authors of every bit of
    code we have would need to agree to that. (Correct me if I'm
    wrong on any of the above points.)

    Do we already have any ISV who'd produce a non-free plugin
    as soon as this API goes in, or is the market you describe

    Last but not least, I feel that adding non-free code into
    the process space of rdesktop would be disadvantegous for
    us, the users and the developers. Instead of seeing this as
    "we'll benefit once we'll have non-free feature X", one can
    see it as "they're bribing us to give up the convenience
    we're used to, in exchange for the "opportunity" use their

  • Simon Guerrero
    Simon Guerrero

    Logged In: YES

    I've had a long, close look at the GPL (including the
    FAQs), specifically with regard to plugins, but the way I
    see it is this:

    Basically, this change isn't the "classic" plug-ins case
    (modifying rdesktop to work with a specific non-free app by
    means of dynamic linking). This is allowing rdesktop to
    take on the functionality of the very technology it was
    reverse-engineered from ( another thorny legal issue ;-] ).
    RDP on windows includes a virtual channel API - it's part
    of RDP. But like I say, this is IMHO. I know this is
    frequently argued elsewhere.

    With regard to the market for this, I have two real names
    of real ISVs who are desperate for this - one of whom is a
    seriously big player, with a contract to supply for a
    10,000+ user base. I don't think they'd be happy with me
    posting their name as I'm under an NDA with them for other
    Linux work, but they are big, and they were all set to just
    violate GPL on this.

    Regarding your final point about "bribing us to give up our
    convenience for the opportunity to use their product" -
    that's an alternative view. But I figure if companies
    really start doing that kind of thing with rdesktop, as
    soon as a useful non-free plugin appears that gets
    reasonably popular, you can bet someone will create a GPL
    version of it. I see it only doing good.

    I didn't intend to get the "everything should be free"
    community up in arms with this change. I was kind of hoping
    to implement something that would keep everyone
    happy... :-/

  • Logged In: YES

    If there wasn't enough community demand for a free
    implementation for this ISV's plugin, why would a non-free
    implementation create that demand? After all, the demand
    steems from server installation of the said product (which
    requires said modification to RDP clients). And it's not
    like a rdesktop-based plugin is easier to reverse engineer...

    How about they work *with* us instead, and have their
    client-side part built-in in every Linux distro around?

    Regarding leveraging functionality from mstsc, that
    functionality being "Virtual channel API", cool - but we
    cannot leverage the licensing terms at the same opportunity;
    we cannot make rdesktop legally eat non-GPL plugins.

    As to reading the "language of the license" and figuring out
    what the GPL authors intended, I think they pretty much saw
    it coming. The naive approach is to think of the GPL as a
    protection against "don't make a small improvement and
    release it as yours, non-free". However, the real scope of
    the GPL is also about "we strive so all software we use will
    be free cause it's useful to us and makes our lives more
    comfortable -- we have a vested interest in that; chose our
    side of the fence and benefit from our assets".

  • Simon Guerrero
    Simon Guerrero

    Logged In: YES

    The ISV we're talking about doesn't have "community demand"
    - it has a userbase on Windows clients that it wants to
    supply with Linux-based ones instead. In fact, both ISV's I
    am specifically aware of have the same requirement.

    The problem is not with them not wanting to have their
    client-side work shipped with every distro - I'm sure they
    love that idea. The problem is that by making the Linux
    versions of their existing Windows virtual channel
    extensions open source, they expose critical details of
    their protocol implementations and "tricks" which loses
    them their commercial advantage over all platforms. I'm not
    just guessing at this - this is why the need for this kind
    of API arose.

    With regard to the licence - other GPL'd apps have got
    around this by adding an "..except for plugins" clause to
    their licence text. But I see how that would grate with
    some of you guys.

    I really do think this is *missing* functionality from
    rdesktop. It's part and parcel of RDP client functionality.

  • Alon Bar-Lev
    Alon Bar-Lev

    Logged In: YES

    The whole point of rdesktop is to provide a free open-source
    RDP client.
    I as a user think this is an important advantage... Providing some
    of the functionality in binary form is not something we want to

    So if the intention of the plugin patch was to bypass the GPL it is
    indeed bad idea.
    When I first commented in favor of the plugin interface is to allow
    GPLed plugins to work with rdesktop.

    Using none GPLed plugin designed specific for GPL application
    is GPL violation. It is exactly as taking the rdesktop code and
    adding a propreitary code. When someone chooses to violate the
    license of open-source application he can do that very easily,
    with or without a plugin interface.

    An exception of this is a plugin like a PKCS#11 provider which is
    not application/implementation specific that may be loaded by
    GPL application (I had a long discussion with FSF regarding this

  • Logged In: YES

    Re "exception clause": That is indeed possible, if each and
    every person whose lines of code reside in rdesktop would
    agree. When we checked in code supplied to us by
    contributors, we never asked them to assign copyright to any
    single body.

    Re "part and parcel", indeed - Virtual Channels and
    extensibility are an integral part of the RDP architecture.
    However, mstsc's licensing model is not, so it's not obvious
    that we should leverage it just as we leverage mstsc's
    technical features.

    I'm not convinced that distinct virtual channel
    implementations are a case of "linkage", rather than a case
    of "program running on a platform", and if so, that it
    couldn't be made under the terms of the CURRENT license.
    This might deserve another thought. However, I am convinced
    that the proliferation of non-free virtual channel
    implementations is against my personal interest in the long run.

  • Simon Guerrero
    Simon Guerrero

    Logged In: YES

    I figured the exception clause would be OK, since copyright
    notices appear (to specific individuals) at the top of each
    piece of source code!

    I agree absolutely and without reserve that proliferation
    of non-free VC apps is a _bad_ thing. But I think that
    support for existing non-free VC apps to encourage the
    proliferation of Linux-based thin clients to be a good

    If we take it as given that ISV's won't want to make their
    VC app implementations public, is there any way out of

  • Brad Hards
    Brad Hards

    Logged In: YES

    I think it is going to be a problem having it in-process.
    Perhaps the interface could be changed to take an
    out-of-process handler (unix domain socket, file
    descriptor or something like that), and run the third
    party code in a separate process.

  • Peter Åstrand
    Peter Åstrand

    Logged In: YES

    bradh, I agree. I was just about to write the same when I
    saw your comment. I think an out-of-process solution would
    solve most issues:

    * It's fine with GPL.

    * The extension cannot interfere with the rdesktop
    internals, so the extensions would be limited to virtual
    channels stuff.

    Using the "inetd" approach (connect stdin/stdout to the
    channel) looks ideal.

    The only problem left is that this *might* mean that closed
    extensions are being developed/deployed instead of open
    ones. I can accept this risk, though.

  • Peter Åstrand
    Peter Åstrand

    • status: closed-rejected --> open
  • Simon Guerrero
    Simon Guerrero

    Logged In: YES

    Thanks for all your feedback. I want to make sure I
    understand this (it's been a long week).

    * A user would specify an executable name as a parameter
    * Rdesktop would open a pipe, then fork and exec
    * Read and write from pipe to use the VC

    I guess this means that incoming data on the channel won't
    act like a 'callback' - the external app would have to keep
    looking to see if there's any data. Or am I missing something?

    This sounds good for me for other reasons too - the
    in-process solution has another disadvantage that I just
    figured out.

    When the "process" function in the external .so gets called,
    it will hang rdesktop until completion (unless the app kicks
    off a thread and returns). This means that rdesktop can't
    interact with the rest of the X system until its event loop
    is given a chance to come back. Out-of-process would get rid
    of this issue too.

    I am happy to go away and redesign based on this. Can you
    guys please give me some ideas of how you think this should
    be done?

    * Currently it uses the -r option and looks for an arg
    ending in .so. Should I define a new -arg?

    * Any other ideas?


  • Peter Åstrand
    Peter Åstrand

    Logged In: YES

    >* A user would specify an executable name as a parameter
    >* Rdesktop would open a pipe, then fork and exec
    >* Read and write from pipe to use the VC


    >I guess this means that incoming data on the channel won't
    >act like a 'callback' - the external app would have to
    >keep looking to see if there's any data. Or am I missing

    Something like this, I think: When rdesktop recieves new
    channel data, it should write the data to the pipe, assuming
    the pipe is ready. We can use select() for this. If the pipe
    is not ready for writing, rdesktop can buffer until it's
    ready. rdesktop should also monitor the pipe for reading:
    When it's ready, rdesktop reads from the pipe and writes to
    the channel.

    The "addin" process can also use select(), if necessary, or
    simply use blocking reads and writes, if allowed by the

    >* Currently it uses the -r option and looks for an arg
    >ending in .so. Should I define a new -arg?

    One idea is:

    -r addin:channelname:/path/to/executable

    I'm using the "addin" keyboard, since that's what MS calls
    the client DLLs.

    Another possibility is to let the executable define the
    channelname. Then it would suffice with:

    -r addin:/path/to/executable

    This could be implemented by having the executable writing
    the channel name (and possible some other initialization
    information) to stdout. One drawback with this approach is
    that we are no longer following the simple inetd model, so
    it would not be possible to re-use plain inetd servers. So,
    I think the first variant is preferred. (This would allow us
    to use servers like Samba over a virtual channel. Pretty
    cool, but of course you'll need support on the server end as

    >* Any other ideas?

    There's already some code in rdesktop for forking and
    reading from a subprocess. Perhaps it can be re-used. The
    lspci should perhaps also be moved from rdesktop to an
    external "addin".

    Please note, though: I'm positive to a mechanism like this,
    but I'm only speaking for myself, not the entire rdesktop
    team. So, we need to have their input as well.

  • Peter Åstrand
    Peter Åstrand

    Logged In: YES

    It should probably be possible to pass arguments to the
    addin as well. So:

    -r addin:<channelname>:</path/to/executable>[:arg1[:arg2:]...]

  • Logged In: YES

    I believe that, as Gtk+ and Qt have demonstrated, one can
    poll both X event queue and other file descriptors in a
    single select, so there's no real need for multithreading.

  • Pierre Ossman
    Pierre Ossman

    Logged In: YES

    >bradh, I agree. I was just about to write the same when I
    >saw your comment. I think an out-of-process solution would
    >solve most issues:
    >* It's fine with GPL.

    I'd have to disagree with this point. The GPL does not
    mention linking as being the blessed form of creating
    "derived" works. In my eyes, a rdesktop specific pipe is no
    different from loading an object into the process memory space.

    That said, this "API" would be so trivial it might not be
    covered. But still, it is by no means clear that it isn't a
    GPL violation.

  • Brad Hards
    Brad Hards

    Logged In: YES

    I think it is a bit zealous to consider that the previous
    authors didn't want rdesktop to be able to communicate
    with a process that isn't GPL'd. After all, that is it
    it's primary feature!

    Which clause of the GPL do you think would be violated?

1 2 3 > >> (Page 1 of 3)