From antoine at nagafix.co.uk  Sun Jul 12 16:33:41 2015
From: antoine at nagafix.co.uk (Antoine Martin)
Date: Sun, 12 Jul 2015 22:33:41 +0700
Subject: [winswitch] [ANNOUNCE] xpra 0.15.3 (minor fixes)
Message-ID: <55A288D5.7040200@nagafix.co.uk>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

This update fixes a fair number of minor issues, none of which are
really critical, but updating is recommended nonetheless.

There is also one "new" feature, which is unusual for a stable update,
that's because the feature is both very unlikely to interfere with
anything (10 lines of code) and very useful for running in containers.
You can now connect to a socket directly by name, ie:
xpra attach socket:/path/to/hostname-$DISPLAY


0.15.3 release notes:
* fix invalid X11 atom
* fix unhandled failure code from libav
* fix default socket permissions when config file is missing
* fix error handling for missing cuda kernels
* fix OpenGL paint early errors
* fix "print" control command with multiple clients
* skip sending invalid packet to client for the "name" control command
* more helpful dpi warning
* support connecting to named unix domain sockets
* OpenGL option can force enable despite platform checks
* replace unsafe deprecated API call in HTML5 client
* more reliable and clean shutdown of connections and threads
* log internal system failures as errors

The source:
https://xpra.org/src/
Binaries/repositories:
https://winswitch.org/downloads/
Direct binary downloads:
https://xpra.org/dists/
Beta:
https://xpra.org/beta/

Cheers
Antoine
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAlWiiNIACgkQGK2zHPGK1rvyugCeJnLlhgHXnHyYkt/GYigmUajj
qhoAniWGvDrzANU04L8GI5nTXVAss2Nw
=uZh3
-----END PGP SIGNATURE-----


From dougdoole at gmail.com  Tue Jul 14 14:53:07 2015
From: dougdoole at gmail.com (Douglas Doole)
Date: Tue, 14 Jul 2015 13:53:07 +0000
Subject: [winswitch] [ANNOUNCE] xpra 0.15.3 (minor fixes)
In-Reply-To: <55A288D5.7040200@nagafix.co.uk>
References: <55A288D5.7040200@nagafix.co.uk>
Message-ID: <CADE5jYKfB44YBOO+UGxtHiBHntkNknKmQzBm_2iQiH+vvpjX9g@mail.gmail.com>

Any idea why this hasn't been pushed out for Ubuntu 14.04 yet?

On Sun, Jul 12, 2015 at 11:33 AM Antoine Martin <antoine at nagafix.co.uk>
wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
>
> This update fixes a fair number of minor issues, none of which are
> really critical, but updating is recommended nonetheless.
>
> There is also one "new" feature, which is unusual for a stable update,
> that's because the feature is both very unlikely to interfere with
> anything (10 lines of code) and very useful for running in containers.
> You can now connect to a socket directly by name, ie:
> xpra attach socket:/path/to/hostname-$DISPLAY
>
>
> 0.15.3 release notes:
> * fix invalid X11 atom
> * fix unhandled failure code from libav
> * fix default socket permissions when config file is missing
> * fix error handling for missing cuda kernels
> * fix OpenGL paint early errors
> * fix "print" control command with multiple clients
> * skip sending invalid packet to client for the "name" control command
> * more helpful dpi warning
> * support connecting to named unix domain sockets
> * OpenGL option can force enable despite platform checks
> * replace unsafe deprecated API call in HTML5 client
> * more reliable and clean shutdown of connections and threads
> * log internal system failures as errors
>
> The source:
> https://xpra.org/src/
> Binaries/repositories:
> https://winswitch.org/downloads/
> Direct binary downloads:
> https://xpra.org/dists/
> Beta:
> https://xpra.org/beta/
>
> Cheers
> Antoine
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iEYEARECAAYFAlWiiNIACgkQGK2zHPGK1rvyugCeJnLlhgHXnHyYkt/GYigmUajj
> qhoAniWGvDrzANU04L8GI5nTXVAss2Nw
> =uZh3
> -----END PGP SIGNATURE-----
> _______________________________________________
> shifter-users mailing list
> shifter-users at lists.devloop.org.uk
> http://lists.devloop.org.uk/mailman/listinfo/shifter-users
>


From antoine at nagafix.co.uk  Tue Jul 14 17:49:33 2015
From: antoine at nagafix.co.uk (Antoine Martin)
Date: Tue, 14 Jul 2015 23:49:33 +0700
Subject: [winswitch] [ANNOUNCE] xpra 0.15.3 (minor fixes)
In-Reply-To: <CADE5jYKfB44YBOO+UGxtHiBHntkNknKmQzBm_2iQiH+vvpjX9g@mail.gmail.com>
References: <55A288D5.7040200@nagafix.co.uk>
 <CADE5jYKfB44YBOO+UGxtHiBHntkNknKmQzBm_2iQiH+vvpjX9g@mail.gmail.com>
Message-ID: <55A53D9D.3020204@nagafix.co.uk>

On 14/07/15 20:53, Douglas Doole wrote:
> Any idea why this hasn't been pushed out for Ubuntu 14.04 yet? The DEBs have just landed now.
Thanks for the reminder!

Antoine

> > On Sun, Jul 12, 2015 at 11:33 AM Antoine Martin
<antoine at nagafix.co.uk <mailto:antoine at nagafix.co.uk>> wrote: >
> Hi,
>
> This update fixes a fair number of minor issues, none of which are
> really critical, but updating is recommended nonetheless.
>
> There is also one "new" feature, which is unusual for a stable update,
> that's because the feature is both very unlikely to interfere with
> anything (10 lines of code) and very useful for running in containers.
> You can now connect to a socket directly by name, ie:
> xpra attach socket:/path/to/hostname-$DISPLAY
>
>
> 0.15.3 release notes:
> * fix invalid X11 atom
> * fix unhandled failure code from libav
> * fix default socket permissions when config file is missing
> * fix error handling for missing cuda kernels
> * fix OpenGL paint early errors
> * fix "print" control command with multiple clients
> * skip sending invalid packet to client for the "name" control command
> * more helpful dpi warning
> * support connecting to named unix domain sockets
> * OpenGL option can force enable despite platform checks
> * replace unsafe deprecated API call in HTML5 client
> * more reliable and clean shutdown of connections and threads
> * log internal system failures as errors
>
> The source:
> https://xpra.org/src/
> Binaries/repositories:
> https://winswitch.org/downloads/
> Direct binary downloads:
> https://xpra.org/dists/
> Beta:
> https://xpra.org/beta/
>
> Cheers
> Antoine
>     _______________________________________________ >     shifter-users mailing list >    
shifter-users at lists.devloop.org.uk
<mailto:shifter-users at lists.devloop.org.uk> >    
http://lists.devloop.org.uk/mailman/listinfo/shifter-users >




From dougdoole at gmail.com  Wed Jul 15 12:12:40 2015
From: dougdoole at gmail.com (Douglas Doole)
Date: Wed, 15 Jul 2015 11:12:40 +0000
Subject: [winswitch] xpra crash on exit
Message-ID: <CADE5jY+7BuddDo1_V+ujSpBhBVHXt8z_AyNBrDs0zfVo06Z2kA@mail.gmail.com>

My system currently has xpra 0.15.3 on the client and 0.15.2 on the server
(both running Ubuntu 14.04). When I exited the client today, it crashed
with the following output:

2015-07-15 07:06:30,708 disconnect_and_quit(0, client exit)
2015-07-15 07:06:30,709 disconnect_and_quit: protocol_closed()
2015-07-15 07:06:30,710 UIXpraClient.cleanup()
2015-07-15 07:06:30,710 XpraClientBase.cleanup() protocol=Protocol(None)
2015-07-15 07:06:30,710 UIXpraClient.cleanup() calling <class
'xpra.client.gtk_base.gtk_keyboard_helper.GTKKeyboardHelper'>.cleanup()
2015-07-15 07:06:30,711 UIXpraClient.cleanup() calling <class
'xpra.clipboard.gdk_clipboard.GDKClipboardProtocolHelper'>.cleanup()
2015-07-15 07:06:30,712 UIXpraClient.cleanup() calling <class
'xpra.client.gtk_base.statusicon_tray.GTKStatusIconTray'>.cleanup()
2015-07-15 07:06:30,712 UIXpraClient.cleanup() calling <class
'xpra.client.notifications.dbus_notifier.DBUS_Notifier'>.cleanup()
2015-07-15 07:06:30,712 UIXpraClient.cleanup() calling <class
'xpra.client.gtk2.tray_menu.GTK2TrayMenu'>.cleanup()
2015-07-15 07:06:30,713 UIXpraClient.cleanup() calling <class
'xpra.platform.xposix.gui.ClientExtras'>.cleanup()
Xpra: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.
[xcb] Unknown sequence number while processing queue
[xcb] Most likely this is a multi-threaded client and XInitThreads has not
been called
[xcb] Aborting, sorry about that.
python: ../../src/xcb_io.c:274: poll_for_event: Assertion
`!xcb_xlib_threads_sequence_lost' failed.
Aborted (core dumped)

This was a one time crash. I have used this combination of client/server
before and after the crash successfully.


From antoine at nagafix.co.uk  Wed Jul 15 12:23:05 2015
From: antoine at nagafix.co.uk (Antoine Martin)
Date: Wed, 15 Jul 2015 18:23:05 +0700
Subject: [winswitch] xpra crash on exit
In-Reply-To: <CADE5jY+7BuddDo1_V+ujSpBhBVHXt8z_AyNBrDs0zfVo06Z2kA@mail.gmail.com>
References: <CADE5jY+7BuddDo1_V+ujSpBhBVHXt8z_AyNBrDs0zfVo06Z2kA@mail.gmail.com>
Message-ID: <55A64299.6070708@nagafix.co.uk>

On 15/07/15 18:12, Douglas Doole wrote:
> My system currently has xpra 0.15.3 on the client and 0.15.2 on the server
> (both running Ubuntu 14.04). When I exited the client today, it crashed
> with the following output:
Was this a normal exit (ie: from the tray) or did you control-C the client?
(snip)
> [xcb] Aborting, sorry about that.
> python: ../../src/xcb_io.c:274: poll_for_event: Assertion
> `!xcb_xlib_threads_sequence_lost' failed.
> Aborted (core dumped)
>
> This was a one time crash. I have used this combination of client/server
> before and after the crash successfully.
Yes, we try very hard to exit cleanly, but I wouldn't worry too much
about it we don't.

Cheers
Antoine


From dougdoole at gmail.com  Wed Jul 15 13:13:52 2015
From: dougdoole at gmail.com (Douglas Doole)
Date: Wed, 15 Jul 2015 12:13:52 +0000
Subject: [winswitch] xpra crash on exit
In-Reply-To: <55A64299.6070708@nagafix.co.uk>
References: <CADE5jY+7BuddDo1_V+ujSpBhBVHXt8z_AyNBrDs0zfVo06Z2kA@mail.gmail.com>
 <55A64299.6070708@nagafix.co.uk>
Message-ID: <CADE5jYJ7OpdyVVyC1waxf-0kLwcZPsx9BsA+wa3Eq49dhfeT7Q@mail.gmail.com>

It was a normal exit from the tray.

Whatever went wrong this time was bad enough that the KDE crash handler
kicked in.

On Wed, Jul 15, 2015, 7:23 AM Antoine Martin <antoine at nagafix.co.uk> wrote:

> On 15/07/15 18:12, Douglas Doole wrote:
> > My system currently has xpra 0.15.3 on the client and 0.15.2 on the
> server
> > (both running Ubuntu 14.04). When I exited the client today, it crashed
> > with the following output:
> Was this a normal exit (ie: from the tray) or did you control-C the client?
> (snip)
> > [xcb] Aborting, sorry about that.
> > python: ../../src/xcb_io.c:274: poll_for_event: Assertion
> > `!xcb_xlib_threads_sequence_lost' failed.
> > Aborted (core dumped)
> >
> > This was a one time crash. I have used this combination of client/server
> > before and after the crash successfully.
> Yes, we try very hard to exit cleanly, but I wouldn't worry too much
> about it we don't.
>
> Cheers
> Antoine
> _______________________________________________
> shifter-users mailing list
> shifter-users at lists.devloop.org.uk
> http://lists.devloop.org.uk/mailman/listinfo/shifter-users
>


From ian.scott-fleming at ttu.edu  Wed Jul 15 18:30:12 2015
From: ian.scott-fleming at ttu.edu (Scott-Fleming, Ian)
Date: Wed, 15 Jul 2015 17:30:12 +0000
Subject: [winswitch] unsubscribe
Message-ID: <F9A34A9C-2F1D-4DF2-8EFA-E3777C5C58F8@ttu.edu>

unsubscribe

Ian Scott-Fleming
Climate Science Center
Texas Tech University
MS 1005
ian.scott-fleming at ttu.edu<mailto:ian.scott-fleming at ttu.edu>








From timothy at hobbs.cz  Sat Jul 18 21:08:25 2015
From: timothy at hobbs.cz (Timothy Hobbs)
Date: Sat, 18 Jul 2015 22:08:25 +0200
Subject: [winswitch] Xpra Xorg launch sequence: using a unix domain socket
 in /tmp/.X11-unix
Message-ID: <20150718200824.GC15275@timothy-debian-hp>

Dear list,

I am the creator of subuser.org. Subuser is a free open source software project (LGPL3) which aims to allow a person to run desktop applications inside Docker containers. Subuser has several aims. One is to make it easier to publish desktop applications on linux by improving portability. Another is to make the desktop more secure by containing those desktop applications within their respective containers.

Right now, the seccond goal is not met. Desktop applications communicate with the host's X11 server by sharing the /tmp/.X11-unix folder with it. This works well, but is completely insecure. I have been waiting for wayland to come out in order to provide a secure solution. However, spurred on by the success of OZ, written by subgraph.com I have begun to reconsider xpra as an intermediate option.

As I want to maintain portability and ease of creating subuser Docker images, I do not wish to install the xpra server in each Docker image which contains a desktop application. In order to maintain this sepparation of requirements, I have come up with the following architecture involving 3 containers:

-------------                      -------------
|desktop app| <--/tmp/.X11-unix--> |xpra server|    Untrusted
-------------                      -------------
                                         ^
                                         | ~/.xpra
                                         v
-------------                       -------------
| host      |  <--/tmp/.X11-unix--> |xpra client|   Trusted
-------------                       -------------

This allows me to run 3 containers.

1) contains the untrusted desktop application
2) contains an untrusted xpra server
3) contains a trusted xpra client

I can use an up-to-date version of xpra, as I do not need to have xpra installed on the host.

The only problem, is that when I run

$ xpra start :100 --start-child=xterm

I don't end up with a unix domain socket in the xpra server's /tmp/.X11-unix directory. This is despite the fact that I have -nolisten tcp set in xpra.conf:

xvfb=Xorg -dpi 96 -noreset -nolisten tcp +extension GLX +extension RANDR +extension RENDER -logfile ${HOME}/.xpra/Xorg.${DISPLAY}.log -config /etc/xpra/xorg.conf

I am confused as to why this is happening, and how I can get a unix domain socket to work with. I cannot use a UDP socket due to the difficulties of sharing UDP sockets between containers.

I have been testing this settup on xpra version 0.14.10

Thank you in advance for your help,

Timothy Hobbs


From timothy at hobbs.cz  Sun Jul 19 09:16:57 2015
From: timothy at hobbs.cz (Timothy Hobbs)
Date: Sun, 19 Jul 2015 10:16:57 +0200
Subject: [winswitch] Xpra Xorg launch sequence: using a unix domain
 socket in /tmp/.X11-unix
In-Reply-To: <20150718200824.GC15275@timothy-debian-hp>
References: <20150718200824.GC15275@timothy-debian-hp>
Message-ID: <20150719081657.GA23770@timothy-debian-hp>

It appears that I have fixed my imediate problem. I was sharing /tmp/.X11-unix using docker volumes, and I needed to run chmod 1777 /tmp/.X11-unix on it to get the permissions the way Xorg wants them :)

Tim

On Sat, Jul 18, 2015 at 10:08:25PM +0200, Timothy Hobbs wrote:
> Dear list,
> 
> I am the creator of subuser.org. Subuser is a free open source software project (LGPL3) which aims to allow a person to run desktop applications inside Docker containers. Subuser has several aims. One is to make it easier to publish desktop applications on linux by improving portability. Another is to make the desktop more secure by containing those desktop applications within their respective containers.
> 
> Right now, the seccond goal is not met. Desktop applications communicate with the host's X11 server by sharing the /tmp/.X11-unix folder with it. This works well, but is completely insecure. I have been waiting for wayland to come out in order to provide a secure solution. However, spurred on by the success of OZ, written by subgraph.com I have begun to reconsider xpra as an intermediate option.
> 
> As I want to maintain portability and ease of creating subuser Docker images, I do not wish to install the xpra server in each Docker image which contains a desktop application. In order to maintain this sepparation of requirements, I have come up with the following architecture involving 3 containers:
> 
> -------------                      -------------
> |desktop app| <--/tmp/.X11-unix--> |xpra server|    Untrusted
> -------------                      -------------
>                                          ^
>                                          | ~/.xpra
>                                          v
> -------------                       -------------
> | host      |  <--/tmp/.X11-unix--> |xpra client|   Trusted
> -------------                       -------------
> 
> This allows me to run 3 containers.
> 
> 1) contains the untrusted desktop application
> 2) contains an untrusted xpra server
> 3) contains a trusted xpra client
> 
> I can use an up-to-date version of xpra, as I do not need to have xpra installed on the host.
> 
> The only problem, is that when I run
> 
> $ xpra start :100 --start-child=xterm
> 
> I don't end up with a unix domain socket in the xpra server's /tmp/.X11-unix directory. This is despite the fact that I have -nolisten tcp set in xpra.conf:
> 
> xvfb=Xorg -dpi 96 -noreset -nolisten tcp +extension GLX +extension RANDR +extension RENDER -logfile ${HOME}/.xpra/Xorg.${DISPLAY}.log -config /etc/xpra/xorg.conf
> 
> I am confused as to why this is happening, and how I can get a unix domain socket to work with. I cannot use a UDP socket due to the difficulties of sharing UDP sockets between containers.
> 
> I have been testing this settup on xpra version 0.14.10
> 
> Thank you in advance for your help,
> 
> Timothy Hobbs
> _______________________________________________
> shifter-users mailing list
> shifter-users at lists.devloop.org.uk
> http://lists.devloop.org.uk/mailman/listinfo/shifter-users


From totaam at gmail.com  Mon Jul 20 03:46:44 2015
From: totaam at gmail.com (Antoine Martin)
Date: Mon, 20 Jul 2015 09:46:44 +0700
Subject: [winswitch] Xpra Xorg launch sequence: using a unix domain
 socket in /tmp/.X11-unix
In-Reply-To: <20150719081657.GA23770@timothy-debian-hp>
References: <20150718200824.GC15275@timothy-debian-hp>
 <20150719081657.GA23770@timothy-debian-hp>
Message-ID: <CAM=3GtWCJkMGcqu4Bx33Xv9UrPsFf2kocvJjhL6ZbAiC467RTA@mail.gmail.com>

I think the wiki could do with some improvements with regards to running
xpra with containers (feel free to edit), until then:
* make sure mmap is enabled (and you can even use a trimmed down build
without any video codecs, which is much safer)
* disable compression
The performance should be very close to native, if not then something is
not setup right.

Cheers
Antoine
It appears that I have fixed my imediate problem. I was sharing
/tmp/.X11-unix using docker volumes, and I needed to run chmod 1777
/tmp/.X11-unix on it to get the permissions the way Xorg wants them :)

Tim

On Sat, Jul 18, 2015 at 10:08:25PM +0200, Timothy Hobbs wrote:
> Dear list,
>
> I am the creator of subuser.org. Subuser is a free open source software
project (LGPL3) which aims to allow a person to run desktop applications
inside Docker containers. Subuser has several aims. One is to make it
easier to publish desktop applications on linux by improving portability.
Another is to make the desktop more secure by containing those desktop
applications within their respective containers.
>
> Right now, the seccond goal is not met. Desktop applications communicate
with the host's X11 server by sharing the /tmp/.X11-unix folder with it.
This works well, but is completely insecure. I have been waiting for
wayland to come out in order to provide a secure solution. However, spurred
on by the success of OZ, written by subgraph.com I have begun to reconsider
xpra as an intermediate option.
>
> As I want to maintain portability and ease of creating subuser Docker
images, I do not wish to install the xpra server in each Docker image which
contains a desktop application. In order to maintain this sepparation of
requirements, I have come up with the following architecture involving 3
containers:
>
> -------------                      -------------
> |desktop app| <--/tmp/.X11-unix--> |xpra server|    Untrusted
> -------------                      -------------
>                                          ^
>                                          | ~/.xpra
>                                          v
> -------------                       -------------
> | host      |  <--/tmp/.X11-unix--> |xpra client|   Trusted
> -------------                       -------------
>
> This allows me to run 3 containers.
>
> 1) contains the untrusted desktop application
> 2) contains an untrusted xpra server
> 3) contains a trusted xpra client
>
> I can use an up-to-date version of xpra, as I do not need to have xpra
installed on the host.
>
> The only problem, is that when I run
>
> $ xpra start :100 --start-child=xterm
>
> I don't end up with a unix domain socket in the xpra server's
/tmp/.X11-unix directory. This is despite the fact that I have -nolisten
tcp set in xpra.conf:
>
> xvfb=Xorg -dpi 96 -noreset -nolisten tcp +extension GLX +extension RANDR
+extension RENDER -logfile ${HOME}/.xpra/Xorg.${DISPLAY}.log -config
/etc/xpra/xorg.conf
>
> I am confused as to why this is happening, and how I can get a unix
domain socket to work with. I cannot use a UDP socket due to the
difficulties of sharing UDP sockets between containers.
>
> I have been testing this settup on xpra version 0.14.10
>
> Thank you in advance for your help,
>
> Timothy Hobbs
> _______________________________________________
> shifter-users mailing list
> shifter-users at lists.devloop.org.uk
> http://lists.devloop.org.uk/mailman/listinfo/shifter-users
_______________________________________________
shifter-users mailing list
shifter-users at lists.devloop.org.uk
http://lists.devloop.org.uk/mailman/listinfo/shifter-users


From Barry at sanpliance.com  Fri Jul 31 02:26:01 2015
From: Barry at sanpliance.com (Barry Smoke)
Date: Fri, 31 Jul 2015 01:26:01 +0000
Subject: [winswitch] awesome project, newbie questions
Message-ID: <SN1PR0101MB14701EE2B0EF7393CA8B1F6ACF8A0@SN1PR0101MB1470.prod.exchangelabs.com>

I stumbled across this project while looking deeper into nomachine nx, and comparable remote protocols.
I spent an afternoon learning about the winswitch gui, and connecting windows pc's together remotely.
the client obviously has full support for the various remote connection protocols, vnc, nx, xpra, rdp, and various others.
there seems to be no way to force a different protocol to be used for windows connections, although the note on the website indicates a licensing issue, not the technology is at fault.
how difficult would it be to enable a selection of the protocol to use for client to client connections on windows, for use as an internal remote assistance utility?
Does the client software act as a server, as I figured out a default port of 32123 is used for connections.
Or, would nx server software, and xpra server software have to be run, to connect the session to?

Is there a design doc, or diagram showing the internal workflow?  I did download the source, but haven't dug through too deep yet.
Thanks,
Barry Smoke



From antoine at nagafix.co.uk  Fri Jul 31 13:00:32 2015
From: antoine at nagafix.co.uk (Antoine Martin)
Date: Fri, 31 Jul 2015 19:00:32 +0700
Subject: [winswitch] awesome project, newbie questions
In-Reply-To: <SN1PR0101MB14701EE2B0EF7393CA8B1F6ACF8A0@SN1PR0101MB1470.prod.exchangelabs.com>
References: <SN1PR0101MB14701EE2B0EF7393CA8B1F6ACF8A0@SN1PR0101MB1470.prod.exchangelabs.com>
Message-ID: <55BB6360.6020007@nagafix.co.uk>

On 31/07/15 08:26, Barry Smoke wrote:
> I stumbled across this project while looking deeper into nomachine nx, and comparable remote protocols.
> I spent an afternoon learning about the winswitch gui, and connecting windows pc's together remotely.
> the client obviously has full support for the various remote connection protocols, vnc, nx, xpra, rdp, and various others.
> there seems to be no way to force a different protocol to be used for windows connections, although the note on the website indicates a licensing issue, not the technology is at fault.
I think you are referring to this page:
https://winswitch.org/documentation/protocols/rdp.html
Every version of windows is capable of running as a RDP server, but
Microsoft charges you more for the privilege.
> how difficult would it be to enable a selection of the protocol to use for client to client connections on windows, for use as an internal remote assistance utility?
I'm not sure what you are asking.
> Does the client software act as a server, as I figured out a default port of 32123 is used for connections.
Usually, the applet starts a local server so that you can also access
session on that machine.
This can be disabled.
The port you refer to is the winswitch port.
> Or, would nx server software, and xpra server software have to be run, to connect the session to?
I don't understand the question, sorry!
> Is there a design doc, or diagram showing the internal workflow?  I did download the source, but haven't dug through too deep yet.
I'm afraid there isn't, only the code and the documentation on the website:
https://winswitch.org/documentation/

Cheers
Antoine
> Thanks,
> Barry Smoke
>
> _______________________________________________
> shifter-users mailing list
> shifter-users at lists.devloop.org.uk
> http://lists.devloop.org.uk/mailman/listinfo/shifter-users




From Barry at sanpliance.com  Fri Jul 31 19:57:00 2015
From: Barry at sanpliance.com (Barry Smoke)
Date: Fri, 31 Jul 2015 18:57:00 +0000
Subject: [winswitch] awesome project, newbie questions
In-Reply-To: <55BB6360.6020007@nagafix.co.uk>
References: <SN1PR0101MB14701EE2B0EF7393CA8B1F6ACF8A0@SN1PR0101MB1470.prod.exchangelabs.com>
 <55BB6360.6020007@nagafix.co.uk>
Message-ID: <SN1PR0101MB1470FE02E6A59F767D6B103ECF8A0@SN1PR0101MB1470.prod.exchangelabs.com>

General statement, I'm trying to get detailed general overview about how winswitch works internally, and why the limitations exist on windows.

See below:

> I stumbled across this project while looking deeper into nomachine nx, and comparable remote protocols.
> I spent an afternoon learning about the winswitch gui, and connecting windows pc's together remotely.
> the client obviously has full support for the various remote connection protocols, vnc, nx, xpra, rdp, and various others.
> there seems to be no way to force a different protocol to be used for windows connections, although the note on the website indicates a licensing issue, not the technology is at fault.
>>I think you are referring to this page:
>>https://winswitch.org/documentation/protocols/rdp.html
>>Every version of windows is capable of running as a RDP server, but Microsoft charges you more for the privilege.

Yes, correct.  The statement:
"Window Switch can only use RDP to connect to a Microsoft Windows machine and forward the desktop to the client's display. 
Although there are other features and other servers, these are not supported at present.
(Mostly due to unnecessary licensing restrictions which have nothing to do with the technology)"
That leads the reader to think that technically, it might be a possibility to enable the functionality, maybe even use a version detection routine to figure out the licensing issue on a per server basis, right?


> how difficult would it be to enable a selection of the protocol to use for client to client connections on windows, for use as an internal remote assistance utility?
>>I'm not sure what you are asking.
> Does the client software act as a server, as I figured out a default port of 32123 is used for connections.
>>Usually, the applet starts a local server so that you can also access session on that machine.
>>This can be disabled.
>>The port you refer to is the winswitch port.
> Or, would nx server software, and xpra server software have to be run, to connect the session to?
>>I don't understand the question, sorry!
> Is there a design doc, or diagram showing the internal workflow?  I did download the source, but haven't dug through too deep yet.
>>I'm afraid there isn't, only the code and the documentation on the website:
>>https://winswitch.org/documentation/

I'll compile the above into one question.  Since the issue of only using rdp is a licensing issue, the questions above are meant to determine the design of winswitch, and routing of sessions.
Is it possible to enable windows to windows xpra, or nx sessions as is, or would xpra server, or nx server need to be ported to windows?


Cheers
Antoine
> Thanks,
> Barry Smoke
>
> _______________________________________________
> shifter-users mailing list
> shifter-users at lists.devloop.org.uk
> http://lists.devloop.org.uk/mailman/listinfo/shifter-users


_______________________________________________
shifter-users mailing list
shifter-users at lists.devloop.org.uk
http://lists.devloop.org.uk/mailman/listinfo/shifter-users