From: SourceForge.net <no...@so...> - 2009-01-23 20:11:36
|
Patches item #1472969, was opened at 2006-04-19 13:17 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=381349&aid=1472969&group_id=24366 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Simon Guerrero (incarnis) Assigned to: Nobody/Anonymous (nobody) Summary: Patch to add API for Virtual Channels Initial Comment: 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, namely: -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 object. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2009-01-23 20:11 Message: A8Irsj <a href="http://lzlutukifbms.com/">lzlutukifbms</a>, [url=http://wknikdglaxku.com/]wknikdglaxku[/url], [link=http://pghbmscrbaut.com/]pghbmscrbaut[/link], http://aitxyafjvxqr.com/ ---------------------------------------------------------------------- Comment By: Simon Guerrero (incarnis) Date: 2008-12-13 22:31 Message: I updated the patch to fix a couple of issues involving an incorrect calculation of the buffer size and response handling. Thanks to "uIm" for pointing them out. ---------------------------------------------------------------------- Comment By: Simon Guerrero (incarnis) Date: 2008-12-13 22:29 Message: File Added: oop.patch ---------------------------------------------------------------------- Comment By: Simon Guerrero (incarnis) Date: 2008-12-13 22:19 Message: File Added: oop.patch ---------------------------------------------------------------------- Comment By: Simon Guerrero (incarnis) Date: 2008-11-19 09:34 Message: Hi all Has anyone had a chance to look at this yet? I have had five queries from other people asking about the status of virtual channel support recently, so there does appear to be interest in this patch. Thanks Simon ---------------------------------------------------------------------- Comment By: Simon Guerrero (incarnis) Date: 2008-10-02 23:58 Message: I have (finally) made the modifications to implement the out-of-process solution previously agreed upon. In order to maintain the visibility of whole data blocks now that external add-ins will be responsible for reading data from the pipe, data written to the pipe is prefixed with a 4-byte long integer which identifies the block size. The external add-in reads 4 bytes first, then the appropriate number of bytes before processing the inbound data. ---------------------------------------------------------------------- Comment By: Simon Guerrero (incarnis) Date: 2008-10-02 23:55 Message: File Added: oop.patch ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2008-03-29 10:01 Message: Logged In: NO Hi...can anyone advise on this please? I don't want to implement something which will be unacceptable from an architectural perspective. Thanks Simon ---------------------------------------------------------------------- Comment By: Simon Guerrero (incarnis) Date: 2007-12-30 17:33 Message: Logged In: YES user_id=1368449 Originator: YES I have this functionality almost ready for release (finally), however it is currently not doing a select() and buffering for writes out to the add-in. I am aware that this will cause rdesktop to hang if there's nobody listening at the other end of the pipe...however, I'm not sure how I can buffer and try later. I have implemented a generic callback in channels.c which is registered for each addin. I've modified the callback mechanism so it also passes the name of the virtual channel in as a parameter to the callback. When data arrives down a virtual channel for an add-in, the generic callback uses the vc name to identify the write pipe into which to drop the data. If I use select() and decide not to write the data, I can add it to a buffer but how do I then retry later? Even if I add something to the main loop which checks if there is any buffered data waiting to send to add-ins, it will only get called when rdp events occur, otherwise it will just sit in rdp_recv. What is the behaviour we *really* want here, and how do I achieve it? The real problem is not how to identify whether the write would block, but rather how we manage to deliver the data in the long run. Thanks Simon ---------------------------------------------------------------------- Comment By: Simon Guerrero (incarnis) Date: 2007-08-14 16:03 Message: Logged In: YES user_id=1368449 Originator: YES > Can someone indicate what the status of this effort is? I see the original patch but not any code that implements the consensus approach. Sorry, this has been on the back burner. Looking to submit a new patch (for the current rdesktop version) shortly. Simon ---------------------------------------------------------------------- Comment By: Bob Pesner (bpesner) Date: 2006-12-15 19:45 Message: Logged In: YES user_id=899391 Originator: NO Can someone indicate what the status of this effort is? I see the original patch but not any code that implements the consensus approach. Thanks ---------------------------------------------------------------------- Comment By: Peter Åstrand (astrand) Date: 2006-06-07 11:23 Message: Logged In: YES user_id=344921 >So I guess I'm not really opposed to the the separate >process solution Good. Everything's clear for implementing this solution, then. ---------------------------------------------------------------------- Comment By: Matt Chapman (matthewc) Date: 2006-06-07 10:54 Message: Logged In: YES user_id=60189 Thinking about it some more, I guess the virtual channel protocol really is just read/write like on a pipe... so the protocol between the parent and child is pretty simple, and this avoids any problems with the child having to interact with the parent's select loop. So I guess I'm not really opposed to the the separate process solution... ---------------------------------------------------------------------- Comment By: Matt Chapman (matthewc) Date: 2006-06-07 10:46 Message: Logged In: YES user_id=60189 In my opinion, this should be a decision on technical grounds rather than legal ones. GPLv2 doesn't specifically address what constitutes a derived work. I'm not sure I agree with the FSFs take on this: to me the process boundary makes no difference, as long as the interface is clearly defined. A separate process that uses a complex private API isn't useful without rdesktop, unless you write another program that uses the same private API, and you can equally well write another program that uses the same library interface. I think either way it would be good to add a licence clarification. Contacting all the past authors may be a challenge, but getting copyright assignment from the past minor authors is probably something that we should do anyway, to improve defendability of the copyright, as recommended by the FSF. The vast majority of the rdesktop code is copyrighted by a small number of people. Moving on to the technical side of it, I can't say I'm a big fan of mandating a separate process. I think for the majority of channels it's overkill (look at lspci for instance, which would be good to move into a plugin, here basically the intermediate process will just be translating the output of lspci... perhaps lspci isn't a typical example though). FWIW Windows virtual channel plugins are usually DLLs running in the MSTSC address space. Are there good technical reasons for the separate process solution? ---------------------------------------------------------------------- Comment By: Peter Åstrand (astrand) Date: 2006-06-07 09:33 Message: Logged In: YES user_id=344921 You have my and Pierres support, but Matt has the final word. ---------------------------------------------------------------------- Comment By: Simon Guerrero (incarnis) Date: 2006-06-07 09:27 Message: Logged In: YES user_id=1368449 Hi guys I have been away for a while so haven't looked at this. I would like to make a start soon at doing the out-of-process solution to this, as we were discussing. Is this OK, or is it still a problem? As per my previous comment, the GPL FAQs seem to back the "out-of-process plugin" option. Thanks Simon ---------------------------------------------------------------------- Comment By: Simon Guerrero (incarnis) Date: 2006-05-08 10:36 Message: Logged In: YES user_id=1368449 Pierre One of the GPL FAQs specifically talks about what is and what isn't a plugin: http://www.gnu.org/licenses/gpl-faq.html#GPLPluginsInNF It sounds as if the out-of-process option satisfies the GPL from this point of view without a problem. Simon ---------------------------------------------------------------------- Comment By: Pierre Ossman (ossman_) Date: 2006-05-08 07:58 Message: Logged In: YES user_id=1469081 My point was that implementing a plug-in API over a pipe instead of function calls doesn't magically free you from GPL's obligations. If you check clause 2 it talks about independent parts and not about specific technical boundaries. My personal opinion, though, is that you'd have to transfer more complex data structures over the pipe before the "plug-ins" would be covered by GPL. Others might think otherwise, so we should check that we don't step on too many toes when implementing a function like this. Hence my "It's by no means clear..." comment. ---------------------------------------------------------------------- Comment By: Ilya Konstantinov (ikonst) Date: 2006-05-08 07:51 Message: Logged In: YES user_id=335423 Brad, you can do a mental exercise and see that any shared library can be turned into an external process with a stream-based protocol. In this case, we're the network carrier and the virtual channel providers are the network applications. This is equivalent to libssl + application. Aren't SSL libraries needing to be LGPL'd to be used by non-free software? Sure they are! How is rdesktop different? ---------------------------------------------------------------------- Comment By: Brad Hards (bradh) Date: 2006-05-08 07:40 Message: Logged In: YES user_id=13687 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? ---------------------------------------------------------------------- Comment By: Pierre Ossman (ossman_) Date: 2006-05-08 07:18 Message: Logged In: YES user_id=1469081 >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. ---------------------------------------------------------------------- Comment By: Ilya Konstantinov (ikonst) Date: 2006-05-06 11:18 Message: Logged In: YES user_id=335423 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. ---------------------------------------------------------------------- Comment By: Peter Åstrand (astrand) Date: 2006-05-06 10:52 Message: Logged In: YES user_id=344921 It should probably be possible to pass arguments to the addin as well. So: -r addin:<channelname>:</path/to/executable>[:arg1[:arg2:]...] ---------------------------------------------------------------------- Comment By: Peter Åstrand (astrand) Date: 2006-05-06 10:48 Message: Logged In: YES user_id=344921 >* 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 Yes. >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? 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 protocol. >* 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 well.) >* 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. ---------------------------------------------------------------------- Comment By: Simon Guerrero (incarnis) Date: 2006-05-06 09:36 Message: Logged In: YES user_id=1368449 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? Simon ---------------------------------------------------------------------- Comment By: Peter Åstrand (astrand) Date: 2006-05-06 08:48 Message: Logged In: YES user_id=344921 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. ---------------------------------------------------------------------- Comment By: Brad Hards (bradh) Date: 2006-05-05 23:46 Message: Logged In: YES user_id=13687 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. ---------------------------------------------------------------------- Comment By: Simon Guerrero (incarnis) Date: 2006-05-05 21:48 Message: Logged In: YES user_id=1368449 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 thing. 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 this? ---------------------------------------------------------------------- Comment By: Ilya Konstantinov (ikonst) Date: 2006-05-05 20:44 Message: Logged In: YES user_id=335423 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. ---------------------------------------------------------------------- Comment By: Alon Bar-Lev (alonbl) Date: 2006-05-05 20:29 Message: Logged In: YES user_id=1157530 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 encourage. 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 issue). ---------------------------------------------------------------------- Comment By: Simon Guerrero (incarnis) Date: 2006-05-05 20:20 Message: Logged In: YES user_id=1368449 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. ---------------------------------------------------------------------- Comment By: Ilya Konstantinov (ikonst) Date: 2006-05-05 20:09 Message: Logged In: YES user_id=335423 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". ---------------------------------------------------------------------- Comment By: Simon Guerrero (incarnis) Date: 2006-05-05 19:53 Message: Logged In: YES user_id=1368449 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... :-/ ---------------------------------------------------------------------- Comment By: Ilya Konstantinov (ikonst) Date: 2006-05-05 19:25 Message: Logged In: YES user_id=335423 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 theoretical? 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 product". ---------------------------------------------------------------------- Comment By: Simon Guerrero (incarnis) Date: 2006-05-05 19:13 Message: Logged In: YES user_id=1368449 Hi 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, IMHO. Simon ---------------------------------------------------------------------- Comment By: Alon Bar-Lev (alonbl) Date: 2006-05-05 14:44 Message: Logged In: YES user_id=1157530 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. ---------------------------------------------------------------------- Comment By: Pierre Ossman (ossman_) Date: 2006-05-05 14:31 Message: Logged In: YES user_id=1469081 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. ---------------------------------------------------------------------- Comment By: Peter Åstrand (astrand) Date: 2006-05-05 14:25 Message: Logged In: YES user_id=344921 >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? ---------------------------------------------------------------------- Comment By: Alon Bar-Lev (alonbl) Date: 2006-05-05 14:09 Message: Logged In: YES user_id=1157530 Hello, 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. ---------------------------------------------------------------------- Comment By: Peter Åstrand (astrand) Date: 2006-05-05 13:53 Message: Logged In: YES user_id=344921 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 project. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=381349&aid=1472969&group_id=24366 |