Update: UltraVNC 1.4.3.6 and UltraVNC SC 1.4.3.6: viewtopic.php?t=37885
Important: Please update to latest version before to create a reply, a topic or an issue: viewtopic.php?t=37864
Join us on social networks and share our announcements:
- Website: https://uvnc.com/
- GitHub: https://github.com/ultravnc
- Mastodon: https://mastodon.social/@ultravnc
- Facebook: https://www.facebook.com/ultravnc1
- X/Twitter: https://twitter.com/ultravnc1
- Reddit community: https://www.reddit.com/r/ultravnc
- OpenHub: https://openhub.net/p/ultravnc
Important: Please update to latest version before to create a reply, a topic or an issue: viewtopic.php?t=37864
Join us on social networks and share our announcements:
- Website: https://uvnc.com/
- GitHub: https://github.com/ultravnc
- Mastodon: https://mastodon.social/@ultravnc
- Facebook: https://www.facebook.com/ultravnc1
- X/Twitter: https://twitter.com/ultravnc1
- Reddit community: https://www.reddit.com/r/ultravnc
- OpenHub: https://openhub.net/p/ultravnc
on hold
- Rudi De Vos
- Admin & Developer
- Posts: 6838
- Joined: 2004-04-23 10:21
- Contact:
on hold
On hold until Aug
- Rudi De Vos
- Admin & Developer
- Posts: 6838
- Joined: 2004-04-23 10:21
- Contact:
Anything to to do help..
Is there antything I can do to help out while you are out.. I'm very excited about this application and can't wait till it is available as a complete release.
- Rudi De Vos
- Admin & Developer
- Posts: 6838
- Joined: 2004-04-23 10:21
- Contact:
Yep, back
SCIII design need to be changed.
It should use the same exe as SCII and repeater.
The SSL implementation need to run as a seperate exe and SC connect in loopback. Same on the repetaer site, the SSL part listen to 443 and connect to the standard repeater ports.
This is more flexable and a lot easier to maintain then different SC versions.
SCIII design need to be changed.
It should use the same exe as SCII and repeater.
The SSL implementation need to run as a seperate exe and SC connect in loopback. Same on the repetaer site, the SSL part listen to 443 and connect to the standard repeater ports.
This is more flexable and a lot easier to maintain then different SC versions.
Rudi,
Can you replace your SCIII_test4.exe by SCIII_test5.exe
http://www.swiss-adsl.net/redge/SCIII_test5.exe
there the file pre-compiled without any change except the winvnc.exe (6 october 2005) based on online creator RC1.0.0
http://sc.uvnc.com/sciii/SCIII_test5.exe
Thank you a lot
Can you replace your SCIII_test4.exe by SCIII_test5.exe
http://www.swiss-adsl.net/redge/SCIII_test5.exe
there the file pre-compiled without any change except the winvnc.exe (6 october 2005) based on online creator RC1.0.0
http://sc.uvnc.com/sciii/SCIII_test5.exe
Thank you a lot
UltraVNC 1.0.9.6.1 (built 20110518)
OS Win: xp home + vista business + 7 home
only experienced user, not developer
OS Win: xp home + vista business + 7 home
only experienced user, not developer
Basically a good idea but this doesn't mean that two different executables are required for SC-III/Repeater/Viewer. You can do the local loopback inside a single executable and have a command line option (e.g. -ssl) for repeater/distributor which activates the SSL listener in front of the normal listener.Rudi De Vos wrote:Yep, back
SCIII design need to be changed.
It should use the same exe as SCII and repeater.
The SSL implementation need to run as a seperate exe and SC connect in loopback. Same on the repetaer site, the SSL part listen to 443 and connect to the standard repeater ports.
This is more flexable and a lot easier to maintain then different SC versions.
It will become too confusing for not so experienced users when there exist multiple executables which must be started in a correct order.
- Rudi De Vos
- Admin & Developer
- Posts: 6838
- Joined: 2004-04-23 10:21
- Contact:
I see... Cool..Rudi De Vos wrote:Enduser release use 2 threads, in one exe via loopback.
But during development 2 exe are just a lot easier.
BTW, I was surfing around in this forum and I have one question.
Is there any Roadmap or Release Schedule for the different products
- UVNC 2 Viewer
- UVNC 2 Server
- New Repeater or Distributor
- SC-III
I can't see any timetable for a new release. One week, one month, one year ?
![Smile :)](./images/smilies/_icon_smile.gif)
Another thing I would highly propose (it was once addressed in another post) is to not fix the SSL listener to port 443. Make it configurable.
Maybe the distributor service is running on a machine (on the INTRANET) where already an IIS or Apache is running on SSL port (443) for internal services but has a lot of free capacity. So I would map the firewall external port 443 to another internal port (e.g. 44343) on this machine (port forwarding with translation). In this case distributor would have to listen on port 44343.
Question: Any plans of a Linux Release of Distributor (as it exists for repeater ?)
BTW, You guys really do a great job ! I am really looking forward to see V2.
Last edited by posbis on 2006-01-07 03:24, edited 1 time in total.
i belive you can configure a not ssl port to what ever you want and then using the regualr viewer (not ssl) to connect and since you plan for a intranet wont be much of a problem not using an ssl connection. i think for this you will have to use a repeater configured with tht ports you wantposbis wrote:
Maybe the distributor service is running on a machine (on the INTRANET) where already an IIS or Apache is running on SSL port (443) for internal services but has a lot of free capacity. So I would map the firewall external port 443 to another internal port (e.g. 44343) on this machine (port forwarding with translation). In this case distributor would have to listen on port 44343.
Yes I understand younolazabal wrote:i belive you can configure a not ssl port to what ever you want and then using the regualr viewer (not ssl) to connect and since you plan for a intranet wont be much of a problem not using an ssl connection. i think for this you will have to use a repeater configured with tht ports you wantposbis wrote:
Maybe the distributor service is running on a machine (on the INTRANET) where already an IIS or Apache is running on SSL port (443) for internal services but has a lot of free capacity. So I would map the firewall external port 443 to another internal port (e.g. 44343) on this machine (port forwarding with translation). In this case distributor would have to listen on port 44343.
![Smile :-)](./images/smilies/_icon_smile.gif)
Customers who need support (my friends
![Smile :-)](./images/smilies/_icon_smile.gif)
I on the other side will connect from my office to the distributor in my Home-DMZ and takeover the support session. (So this second connection is going over public INTERNET as well.)
This is why I need SSL and why I would like to port forward 443 to another port on a server in my Home-DMZ where already an Apache is listening on 443. This means that distributor must listen on a different port than 443 for SSL because 443 is already the official HTTPS of my Apache.
Regards,
Oliver
Posbis.
There is one problem you need to keep in mind when using another port than 443 for your SSL communication.
Some customer might have very restricted rules for outbound traffic in their firewalls that prevents outgoing traffic on ports other then well known port like FTP HTTP HTTPS (SSL).
Also keep in mind that the users that are using a proxy server to access the Internet will not be able to connect to your distributor if you aren't using port 443 for the SSL communication.
Most Proxy servers will not default accepts "tunnelling" on other ports than 443.
However, today there seems to be a general problem with the SCIII to connect through some proxy servers.
(See [topic=6063][/topic])
So if you're looking for an app that just will work all the time for everybody you need to use port 443.
One thing that has been bugging me is that using the SSL distributor that will accept SCIII SSL connections will also automatically accept VNCViewer_SSL connections.
I'm using SC (not SCIII) with the distributor today where the SC communicates goes through a SSL wrapper. In this case we can allow only SC to connect to the distributor over the public SSL port but the VNCViewer can only connect from the internal network. This prevents that user outside our organisation can use our distributor to connect to our customer.
This might be something to consider while developing the SCIII with distributor that it should be optional to prevent VNCViewers to connect through SSL.
Cheers
/M
There is one problem you need to keep in mind when using another port than 443 for your SSL communication.
Some customer might have very restricted rules for outbound traffic in their firewalls that prevents outgoing traffic on ports other then well known port like FTP HTTP HTTPS (SSL).
Also keep in mind that the users that are using a proxy server to access the Internet will not be able to connect to your distributor if you aren't using port 443 for the SSL communication.
Most Proxy servers will not default accepts "tunnelling" on other ports than 443.
However, today there seems to be a general problem with the SCIII to connect through some proxy servers.
(See [topic=6063][/topic])
So if you're looking for an app that just will work all the time for everybody you need to use port 443.
One thing that has been bugging me is that using the SSL distributor that will accept SCIII SSL connections will also automatically accept VNCViewer_SSL connections.
I'm using SC (not SCIII) with the distributor today where the SC communicates goes through a SSL wrapper. In this case we can allow only SC to connect to the distributor over the public SSL port but the VNCViewer can only connect from the internal network. This prevents that user outside our organisation can use our distributor to connect to our customer.
This might be something to consider while developing the SCIII with distributor that it should be optional to prevent VNCViewers to connect through SSL.
Cheers
/M
Last edited by mabj on 2006-03-10 07:47, edited 2 times in total.