nx-libs
nx-libs copied to clipboard
Additional channels for nxcomp.
There is a suggestion to add additional channels to nxcomp. The technology is already used for usbip and authorization schemes in commercial products based on nx. Sorry for the English curve :)
IIRC there's already similar code contributed by qvd: 30af52eb324f6bf5551869033605e3141d745a40
Regarding your patch: Instead of hardcoding three additional channels I really would like to see some dynamic solution where the code can handle an arbitrary number of channels defined in the config. Like multiple extra= statements defining the port and a short description, e.g. extra=7000:"usbip":required,extra=7100:"special_auth":mayfail,...
Regarding usbip: do you have any code you could contribute? This is a long sought feature...
@uli42: @dimbor-ru: external application/protocol forwarding support changes should/must be coordinated with devs from Qindel, as they heavily use that feature whereas X2Go is not using it.
@vatral: please take notice of this discussion on nx-libs issue #873 or point the right person at Qindel to this. Thanks.
@dimbo-ru: good to have you share your work with us here. Thanks + much appreciated. I'd love to see all your improvements, use case fixes, etc. addressed in the nx-libs upstream version, so that you basically don't have to maintain you own branch over the long run. Don't worry about your English, it's fine. (We are all Germans, so probably not better English, esp. when we start speaking in English ;-) ).
@dimbor-ru: dp you think you can dissect your diff between this nx-libs an etersoft's nx-libs and wrap the changes atomically into Github pull requests. This would make it most easy for us to discuss the proposed changes and review code fragments. Thanks.
@sunweaver: I am flattered by the assessment of my modest old work. Of course, our further interaction will occur in the form of my pool requests. On the other hand, for important things, form is not so important. And the little things will remain trifles both in Africa and in the Arctic (there was an attempt to make a joke ;).
@uli42: Programmers from Etersoft have written some usbip support code for linux servers and clients, but are not yet ready to open it. And a couple of years ago I was stopped from implementing this idea by the lack of an open usbip server for windows.
On Fri, Nov 15, 2019 at 4:26 PM dimbor-ru [email protected] wrote:
@uli42: Programmers from Etersoft have written some usbip support code for Linux servers and clients, but are not yet ready to open it. And a couple of years ago I was stopped from implementing this idea by the lack of an open usbip server for windows.
So will this be released one day as open source?
Uli
I'm not an employee of Ethersoft, I only advise them sometimes. Therefore, I can't speak on their behalf.
Ah, thanks for clarifying that. I have done some more clipboard patches you might want to test: https://github.com/uli42/nx-libs/tree/pr/more_clipboard_improvements
On Mon, Nov 18, 2019 at 12:58 PM dimbor-ru [email protected] wrote:
I'm not an employee of Ethersoft, I only advise them sometimes. Therefore, I can't speak on their behalf.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ArcticaProject/nx-libs/issues/873?email_source=notifications&email_token=ABQHBZGCDLQFAE5AVMZPFXTQUJ7O3A5CNFSM4JNSVS42YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEEKGQNQ#issuecomment-554985526, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABQHBZHIDI3NGZXEMZSTAU3QUJ7O3ANCNFSM4JNSVS4Q .
However, I was prompted with a promising project: usbip-win But I'm not so friendly with MSVS for experimenting with it. While he is waiting for brave guys.
Thanks for the pointer! Looks promissing indeed. As these are separate components I'd rather add that to x2go instead of nx-libs.
On Thu, Jan 2, 2020 at 12:32 AM dimbor-ru [email protected] wrote:
However, I was prompted with a promising project: usbip-win https://github.com/cezanne/usbip-win But I'm not so friendly with VC for experimenting with it. While he is waiting for brave guys.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ArcticaProject/nx-libs/issues/873?email_source=notifications&email_token=ABQHBZACR3N4YIKU7TGEY5TQ3URYJA5CNFSM4JNSVS42YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEH5OZOI#issuecomment-570092729, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABQHBZCLY6T5K6CARFYM4ETQ3URYJANCNFSM4JNSVS4Q .
Note that man nxproxy contains this:
mask=<int>
Determine the distribution of channel ids between the proxies.
By default, channels whose ids are multiple of 8 (starting from
0) are reserved for the NX client side. All the other channels
can be allocated by the nx-X11 Agent side.
Yes, I assumed that changing the CHANNEL_MASK to 0x0F would violate the nx-protocol in some way. However, when tested, it worked. Naturally, all possible modes were not tested. Please note that the mask changes on both the server and client sides. So it may not be as bad as it seems.