on hold

[Rudi De Vos]

On hold until Aug

[odontech]

Why! This would be such a GREAT product!

[Rudi De Vos]

3 weeks Holliday

[odontech]

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.

[netwolf]

3 weeks Holliday

Have a great time ! You really deserve it

[eo]

Rudi De Vos,

Are you back from your vacaction? We missed you - hope that your batteries are recharged and ready to tackle SCIII!

[Rudi De Vos]

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.

[redge]

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

[kronos5150]

Rudy:
This version seems to based on the OpenSSL source ?

I noticed them .pem file.

Are combining something similar to Stunnel/OpenVPN with VNC ?

Long time Admin / Newbie Coding ...


Just curious ..

[posbis]

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.

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.

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]

Enduser release use 2 threads, in one exe via loopback.

But during development 2 exe are just a lot easier.

[posbis]

Enduser release use 2 threads, in one exe via loopback.

But during development 2 exe are just a lot easier.

I see... Cool..

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 ? Just asking ...

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.

[nolazabal]

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.

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 want

[posbis]

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.

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 want

Yes I understand you but it is not want I want. I am not planning to use this on the INTRANET. I just want to run the distributor on the INTRANET or in a DMZ (my Home-DMZ).

Customers who need support (my friends will go to a website of mine where they can start the SC-III client already preconfigured to connect to my distributor (so this goes over public INTERNET).

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

[mabj]

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)

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