about Design and implementation Daylight license server 4.71ex [Image] 2000 01 26 16:48:59 UTC Home Status Manager Help Design and implementation of daliserver Here is where we get a chance to describe motivations behind the design and implementation of daliserver. Customers don't actually need to know this stuff to use our software. The rest of the help package describes "how"; this page describes the "why" behind it. Background Daylight Chemical Information Systems produces a variety of chemical information tools including: programs, OOP toolkits, Java widgets, database servers and chemical data sets. Daylight's product list has grown surprisingly large over the years. Most of these products are Daylight Software, but some are third-party products repackaged by Daylight (e.g., clogp and databases) and in some cases Daylight software is repackaged by others. Licensing arrangements are necessarily complex because they must accomodate vendor's requirements (Daylight, third-party vendors) as well as the needs of a wide variety of customers (from individual academics to global corporate entities). History For over a decade, Daylight has produced software with an embedded license manager, i.e., an internal part of each program which requires that a valid, external license file be present. This approach has benefited customers and third-party vendors as well as Daylight. We have been able to distribute the software on WWW mirrors and be generous with "trial" and "demonstration" licenses. The existing Daylight license manager still does a great job. Not bad for software written more than a decade ago (when web-mirrors were barely a glint on the horizon). Getting on... However, good ol' dy_lm() is starting to show its age, due to the advent of pervasive network computing as well as changes in Daylight's customer base. A decade ago, it seemed reasonable to license individual computers to do high-performance chemical information tasks. After all, how many high-performance computers do you need? How many can one entity afford? From today's POV, the answers are, "Many!" or "(At least) one per chemist." For example, when Daylight sells a global license to a company, they have the right to run the software on all the computers they use, i.e., hundreds to thousands of them. It seems a little absurd that our license manager requires each one to have its own license file. With Internet applications in the Daylight works, the scale of this problem is going to get bigger, quickly. A network license service The Dali service is our solution to this problem. Our goal is to provide a license management service which supports all the good aspects of the current system, immediately simplifies license management from both Daylight's and customers' POV, and which provides a flexible and scalable path for future license arrangements. Using a network service for this is the obvious choice: the network is the only reason that 1000's of computers can be useful, so we might as well use the network to manage licensing (as well as basically everything else we do...). An HTTP service! The "shape" of the license manager started as a multi-port stateful server but unexpectedly evolved into a simple, pure HTTP service. Using HTTP for control and monitoring was a no-brainer ... today's GUI of choice is a web-browser. But for actual licensing functions, a large number of protocols could work well ... HTTP-, TDT-, JRMI-, and XML-based protocols were each implemented experimentally. A straightforward HTTP protocol was the clear winner. Since we would be using HTTP for control and monitoring, it also had the minimal fuss-and-bother factor. Basic operation as a license information service Here's how the Dali server works as a license manager. The program daliserver is an HTTP web server, which means that it responds to HTTP requests in a predictable fashion. HTTP requests include a request type (HEAD, GET, POST), a URL, and sometimes other interesting information (e.g. form contents). The two most common responses are "200 OK" and "404 Not Found". That functionality is all that is needed for a license request, and that's exactly how Dali implements it. An example. Let's say the Dali server is running on host "lama",and we want to check if the computer with CPU ID "abcdef01" is licensed to run the program "fingerprint" We ask the daliservice for the URL: http://lama:5581/dali/lic/cpu/abcdef01/program/fingerprint which returns "200 OK" if it's licensed or "404 Not Found" if not. If we make this request from a web browser, it appears as a GET request, so along with the 200 or 404 header, daliserver adds a bit of HTML to the reply for the user's viewing pleasure. For normal license managment purposes (such as the fingerprint program checking to see if it's licensed to run on a certain machine), only a HEAD request is sent and only the headers are returned, which saves a bit of overhead. Neat, huh? Control and monitoring This is the tidy part of using HTTP: control and monitoring functions are done exactly as if daliserver were a web server providing access to CGI programs (which is, in fact, exactly true). The URL: http://lama:5581/ is daliserver's "home page", which contains links to explanations, status pages, search functions, forms ... just like the HTTP browser that it is. The page you are reading right now would be served as URL: http://lama:5581/dali/help/design Dali server goes the "whole way" as an HTTP server and responds properly to POST requests with multipart form encoding, Netscape Cookie headers, etc. This means that managers can conveniently authenticate themselves and upload license files by name or by content. Implementation in Daylight Release 4.71 The initial daliserver implementation will be deployed with Daylight v4.71 in 2Q2000. All Daylight 4.71 clients, toolkits and servers will be linked with a daliserver-aware license manager. This license manager will have the capability of using the Dali network service and/or local license files. Operation will be under end-user control: if DY_DALI_SERVICE is defined, it will be used; if not (or if it fails) operation will revert to pre-4.71 behavior, i.e., based on local license file DY_LICENSEDATA. All current license files will continue to be valid. In fact, the format of new license files will not change at all except that they can include the "#hostname:" comment for user's convenience. The one big difference is that license files for all computers on a network can reside in a single place (on the daliserver host). Beyond the basics: automatic license updating An exciting prospect using networked license managers is automatic license updating. It's hard to believe today, but we used to actually FAX license files to customers who would type them in! Yes, typographical errors were common. Our customers were good sports but it got to be a tiresome process. Fortunately, e-mail came along and pretty much solved the problem of typos in license files. The current procedure is for Daylight Support to e-mail license files to customers who edit the descriptive text out of the e-mail then save and install the resulting license file. It's a better system, but it's still a lot of work that needs to be done with many 100's of files per year. Dali servers have the ability to communicate with each other. Why not have daliservers at customer sites automatically download license files from the daliserver at Daylight Central? Why not, indeed? We can't think of a reason, so this capbility has been implemented in daliserver in the following manner: A customer can optionally specify the name of an HTTP proxy server which will be used to contact http://www.daylight.com:dali/ for license updates at regular intervals (default: once per week). If a new license is available for the local network being served, it will be downloaded, saved and logged. If the customer does not specify a proxy server for automatic update, no such requests will be made. Note that this protocol simply makes an HTTP request through a proxy in the same way as any other web browser request. Automatic license updating may or may not make the cut for 4.71. Beyond the basics: network licensing As time goes on, it seems to make less sense to license software for use on specific computers and more sense to license software for use on a specific networks (or possibly subnets? or net & netmask?). Although it is not yet clear how this might affect licensing arrangements, it will be easy to implement such network licenses using daliserver. A request for a network license would look like this: http://lama:5581/dali/lic/net/207.17.60.12/program/fingerprint Compare this to the cpu-bound license request shown earlier. Should the javagrins license be implemented in this manner? [Image] Daylight Chemical Information Systems, Inc. daliserver 4.71ex