|TCP/IP & Helix Server 5.0-5.2|
This note discusses the TCP/IP implementation in Helix 5.0 through 5.2.1. If you are using Helix 5.3 or later this link will take you to the correct page.
The TCP/IP implementation in Helix 5.0 through 5.2.1 is a rudimentary implementation. Significant enhancements have been made and are available in Helix 5.3 and later releases. A description of Helix's current TCP/IP implementation is found on the Helix Client/Server and TCP/IP page.
|Can I have some Client visit via TCP/IP and others via AppleTalk?||
No, Helix Server can only support one communications protocol at a time.
|Why doesn't Helix TCP/IP work with my internet setup?||
In most cases, the root of the architectural difficulty is attributed to the asynchronous communication that happens between Helix Client and Server. Not only can the Client initiate communication (similar to a web browser requesting a page) but the Server must also be able to initiate communication as well.
Therefore the IP Addressing scheme used on both ends must be such that the Helix application at either end can initiate contact when necessary.
|What does "asynchronous communication" mean?||
Asynchronous communication is at the core of Helix Client/Server interaction. Although you may typically think of Helix Client/Server as being driven by the Client, there are a great many things that are initiated by the Server as well. Remember that the Helix Client/Server architecture features live updating of information on the Client's screen. To do this, the Server must be able to initiate contact with a Client when the data they have accessed is changed.
Without asynchronous communication you would not be able to open another view while waiting for a list to draw. If you use dynamic popups on entry views, you would have to wait until all of the popup data was delivered to the Client before you could begin to work on the view. You may not notice that dynamic popups are not instantly available on a typical view when the Client and Server are on an Ethernet network, but when the Client is on a 56K modem, there will be a noticeable delay if the popup contains much data or is restricted by a complex query.
|Does Helix TCP/IP work with both public and private IP Addressing?||
If you are using TCP/IP solely on an intranet, then you can use private addressing. But if you intend to communicate across the internet, then both machines must have public IP addresses. The Client can have a "dynamic" IP address (one that changes from session to session, as it would with a typical dial up connection) but the Client must be assigned a public IP address so the Server can contact it when necessary.
|How can I tell if my IP Addresses are public or private?||
The Internet Assigned Numbers Authority (IANA) has reserved the following three blocks of the IP address space for private networks:
010.000.000.000 - 010.255.255.255
So if your IP Addresses that begin with 10, 172, or 192, you are probably using private IP addressing. Contact your network administrator or ISP to know for certain.
For a detailed discussion of IP Addressing a Sherlock (or google) search of the internet for "private IP addressing" will turn up many more references.
|Can I put my Helix Server behind a firewall?||
Yes! This technote explains how to configure your firewall if you want to provide access to Clients outside your local network.
For more information on firewalls, see this page from techtarget.com.
|Can I put my Helix Client behind a firewall?||
No! See the technote referenced above for discussion regarding this problem.
|What about Proxy servers?||
Because of the two-way initiation requirement, going through a Proxy server is out of the question. The purpose of a Proxy server is typically to shield the end user (the Helix Client) from direct contact with the Server. Without a direct communication channel, Helix TCP/IP will not work.
For more information on Proxy servers, see this page from Vicomsoft.
|What about IP Addresses assigned by DHCP servers?||
If a Client is in an office where private IP addresses are assigned (typical with DHCP Address servers) it will not be able to maintain communication with a Helix Server in another location. Although DHCP servers typically assign private IP Addresses, they can often be configured to issue public IP Addresses. A Client that receives its IP Address from a DHCP server configured in this way should work.
For an overview of DHCP, see this page from Vicomsoft.
For detailed information on DHCP, visit the dhcp.org website.
|What about NAT (Network Address Translation)?||
NAT will not work because Helix Server must contact the Client directly on any number of randomly assigned ports.
When Helix Server needs to contact a client, it opens a new port and starts a separate communication. Asynchronous communication requires this. When Helix Server needs to send a message to a Client, it looks for an open port and when it finds one, it uses it to initiate contact and send the data. If Helix were limited to a specific range of ports, a situation could arise where no ports were available, and communication would stop. An example of this is a dynamic popup. When a view is opened, each dynamic popup is "spun off" as a separate task for the Server to work on. Even while a dynamic popup is still being calculated, the rest of the form is available for the user to work on. A dynamic popup that is still calculating is evidenced by a grey selector triangle. When the popup is ready, Helix Server contacts the Client and sends the data. The Client receives the data, fills the popup, and makes the selector triangle black, to indicate that the popup is ready. The dynamic popup calculation is an asynchronous task. If the Server was not able to open a port to the Client on its own, it would never be able to make the form fully active. If the Server was restricted to opening certain ports, it could be put in a situation where those ports were already opened by other tasks and the dynamic popup's data delivery would be delayed significantly.
NAT requires that you map specific ports to specific machines, an impossibility given these requirements.
For a detailed discussion of IP Addressing, see this page from Vicomsoft.
|Does Helix Client/Server encrypt the transmitted data?||
No encryption. Passwords are protected, but the record data is sent as unencoded data. However, to the untrained eye, only text fields are sent as plain text. All other data types are stored (even in the database itself) in some sort of encoded format and they are transmitted in encoded form.
If you have a packet sniffer (we recommend Interarchy) you can observe the data flow for yourself. Download current Helix Client and visit our tech support server at techdb.qsatoolworks.com. Log in as guest. With Interarchy open and set to show all TCP streams, you'll see exactly what gets sent over the wires.
|Where can I learn more about the internet and networking issues?||
Whatis?com is an excellent site that covers these issues in great detail.