by
Martyn Leadley >> Thu, 10 May 2001 3:08:53 GMT
I presume when you say it supports proxies, you are assuming that the proxy server has port 443 unblocked, which I agree is a perfectly valid assumption.
However what if you can't use port 443? - then your app is back at the mercy of the proxy as to whether or not is has your particular port unblocked, and chances are it would be blocked.
We host our own Jade apps for clients and we currently have 3 thin client enabled seperate systems running on the one web server. Straight away this means we have to have 3 different port numbers for the 3 app servers. One lucky client gets to have port 443 for their appServer, and therefore have no issues with proxies, but the other clients have to have a different port number, and therefore proxy servers are a big issue to them.
The default port number used when SSL is enabled is 443. This can be changed
via the use of a ini file setting, for example
[JadeThinClient]
SSLSecurePort=444
and
[JadeAppServer]
SSLSecurePort=444
As always the firewall / proxy server has to allow tcp/ip traffic through the
selected port number.
Which then begs the obvious question - why can't all appServers work on port 443?
The web can handle numerous web requests on the one machine all using port 443, so why can't Jade? The web uses host headers (Eg
www.mydomain1.com, or
www.mydomain2.com) to know which site the traffic is for, can Jade not do something similar?
Could we give the appServer a name, then set up the thin clients appServer setting to point at the particular named system of interest?
Eg.
Thin Client 1 >> appServer=210.54.249.19:MyFinanceSystem appServerPort=443
Thin Client 2 >> appServer=210.54.249.19:MyCallCentreSystem appServerPort=443
Thin Client 3 >> appServer=210.54.249.19:MyFarmersSystem appServerPort=443
This would then allow 3 appServers to all be hosted on the one Server (210.54.249.19), but all systems can use port 443 as their appServerPort, instead of the current setup where each of those systems would have to have their own port.
To do as you suggest we would have to implement some form of routing on the web server. One program would listen on a port, 443 for example, and then read the header, and then pass it to the correct appserver. The major down side to this is that every thin client message would need extra data imbedded
in it to allow for the routing. This would increase the size of the data and slow things down.
As far as wanting multiple appserver to use the same port number on the same host, the following applies.
TCP/IP will not allow multiple programs to concurrently listen on the same ip interface and port number. The appserver by default opens the port number on all available interfaces. A netstat -an will show this as
Proto Local Address Foreign Address State
TCP 0.0.0.0:443 0.0.0.0:0 LISTENING
So if the host running the appserver has multiple network interface cards, it has effectively grabbed port 443 on all interfaces. If you wish you can force the appserver to only listen on a specific interface by adding AppServer=<ipaddress|hostname> entry to the ini file, for example
[JadeAppServer]
AppServer=210.54.249.19
Which will only grab the 210.54.249.19 interface. The reason for supporting this is to support the situation you mentioned above. If you can create multiple IP addresses on the same network card, then you can have multiple appservers all listening on the same port number. How you create IP address aliases is operating system specific.
So if the interface card has address 210.54.249.19 and you add 210.54.249.20 and 210.54.249.21 as aliases, then each appserver can be given a different IP interface address to listen on. Net result is 3 appserver on one host with
one network card all listening on port 443. The smart thin clients will need
to be told which ip address / hostname to connect to, but they will all be using the same port number.
A side benefit of this, is that if the load on the host grows to the point you need to move an appserver to another host, just move it and reassign the ip address alias to the new host. That way the clients do not need to change
their connection details.
Martyn