SNTPCLNT is a SNTP client for NetWare 3.x, 4.x, and 5.x Servers. SNTP stands for Simple Network Time Protocol, and should not be confused with the SMTP or SNMP protocols.
What can SNTPCLNT do for you?
Imagine you have a direct connection to the internet, or you have a UNIX system with an atomic clock. Now, the hardware clock of your Novell server is not very exact, and you have to readjust the time every 2-3 weeks.
So would it not be nice to ask a host on the inter/intra-net about the current time/date and adjust the server according to this answer? If the answer is yes, then you need my utility.
What do you need to use this utility ?
NetWare 3.x, 4.x, or 5.x server with TCP/IP installed - Direct connection to the internet - My utility, either the NetWare 3.x or 4.x version
-Optionally sntpclnt can benefit from an installed DNS resolver (only 4.x/5.xversion)
How to use SNTPCLNT
First you must decide whether you have a 3.x, 4.x, or 5.x server. If you don't know what version of server you have ;-), use the version for the 3.x servers, since this works on 4.x or 5.x servers too.
Then you copy the SNTPCLNT.CFG file in the SYS:ETC directory and customize it to your needs.
SNTPCLNT will now contact the given host(s), and set your clock accordingly. If you have specified an interval, then the NTPserver(s)will be polled again, and again and again and again and...
You can specify up to 10 (S)NTP servers. SNTPCLNT then contacts each server, calculates the "average" time of the servers, and then sets your server to this synthetic time. It is a good practice to specify at least 3 time sources from the internet, so if you get some unusual transmission delays (as is normal in the internet on peak hours) then the other two servers will almost completely compensate this delayed time.
With this you get two advantages:
- When a (S)NTP server fails or is unavailable, then the chance is big that another of the list can give you a correct answer.
- When you have relatively high transmission delays (slow links, rush-hours, etc.) then the received time is more accurate, since peak-loads on the net do not much influence your client.
Of course, you can specify the same (S)NTP server multiple times. It is then just asked multiple times for the current time, just as if it would be another server.
Known problems / untested cases
In the year 2036 SNTPCLNT will return wrong dates (switch back to 1900). The workaround to this problem (as described in RFC2030) is not implemented. I think I still have some time to implement this, if there will still be NLMs running in 40 years. (The year 2000 problems tell us that this can happen)
What are the costs for all this?
SNTPCLNT is shareware. You can get an activation key from the Web site, which will activate the program for one month. With the utility regkey.exe you apply the key to the NLM.
SNTPCLNT is licensed on server basis. For each server you load SNTPCLNT you must obtain a license.
Please have a look at www.neatech.ch/sntpclnt for the current registration information.
Where to get new versions
The place to get SNTPCLNT is at http://www.neatech.ch/sntpclnt/
Due to the nature of the (NetWare) environment, there are a few things you should know about
- The SNTP protocol transfers the time in a 32-bit unsigned integer, in seconds relative to 0h on 1 January 1900. This means that the 32-bit number will overflow some time in 2036 (second 4,294,967,296). Currently this condition is not handled correctly in my utility. If I see that it is used on a regular basis by a lot of users, I will implement a fix for this condition.
- The NTP protocol is described in RFC 2030 (previously 1769)
- Normally you don't need to check your time very often. Once after server startup (in the AUTOEXEC.NCF would be a fine place) and then once day would be enough. Of course you can check more often, but this helps nothing, since the clock is only accurate to 1.5 seconds. So don't take bandwith and processing time for nothing, since the NTP servers who offer those services don't get any money from you for offering you these services.
- NMX (NetBasic) support, currently not available. Does it make sense to implement this ???
- You can specify hosts either as IP numbers or as DNS names. But for using DNS names, you must have a working DNS resolution installed on the server. netdb.nlm must be loaded. The 3.x version does not use DNS at all, only the etc/hosts file.
- For a more detailed info about NTP look at this site: http://www.ntp.org
- There exists an older utility called RDATE in at least two different implementations. RDATE is based on RFC 868, SNTPCLNT is based on RFC 2030. Basically RDATE does the same as SNTPCLNT, but SNTPCLNT has a slight advantage, since it uses a better time protocol. (And you will find more servers who provide (S)NTP services than RDATE services)
The beta versions of SNTPCLNT should not be redistributed in any way.
The final release versions can be distributed, but the package must always include all files as in the original distribution.
You can distribute SNTPCLNT as part of your solution, but you have no right to sell it in any way to your customers. (Unless you buy a license for this client)
I do not guarantee SNTPCLNT behavior. You use this software at your own risk.