HANDLE.NET (Ver. 8.1) Technical Manual 
HANDLE.NET​
®
(version 8.1)  
Technical Manual  
Version 8.1 
Preliminary edition 
Corporation for National 
Research Initiatives 
November 2015 
hdl:20.1000/105 
Create thumbnail from pdf - control software system:C# PDF Thumbnail Create SDK: Draw thumbnail images for PDF in C#.net, ASP.NET, MVC, Ajax, WinForms, WPF
Support Thumbnail Generation with Various Options for Quick PDF Navigation
www.rasteredge.com
Create thumbnail from pdf - control software system:VB.NET PDF Thumbnail Create SDK: Draw thumbnail images for PDF in vb.net, ASP.NET, MVC, Ajax, WinForms, WPF
Support Thumbnail Generation with Various Options for Quick PDF Navigation
www.rasteredge.com
HANDLE.NET (Ver. 8.1) Technical Manual 
Handle.Net 8.1 software is subject to the terms of the Handle.Net Public License Agreement 
(version 1). Please read the license: ​http://hdl.handle.net/20.1000/103​
© Corporation for National Research Initiatives, 2015, All Rights Reserved. 
Version Note 
Handle.Net Version 8.1 Software, released in 2015, constituted a major upgrade to the 
Handle.Net Software.  Major improvements include a RESTful JSON-based HTTP API, a 
browser-based admin client, an extension framework allowing Java Servlet apps, authentication 
using handle identities without specific indexes, multi-primary replication, security 
improvements, and a variety of tool and configuration improvements.  See the Version 8.1 
Release Notes at ​http://www.handle.net​
for details. 
Please send questions or comments to the Handle.Net Administrator at 
hdladmin@cnri.reston.va.us​
, or your prefix administrator. 
control software system:How to C#: Generate Thumbnail for Word
Images. Convert Word to ODT. Convert PDF to Word. Convert ODT to Text Search. Insert Image. Thumbnail Create. Thumbnail Create. |. Home ›› XDoc.Word ›› C# Word
www.rasteredge.com
control software system:VB.NET Image: Program for Creating Thumbnail from Documents and
language. It empowers VB developers to create thumbnail from multiple document and image formats, such as PDF, TIFF, GIF, BMP, etc. It
www.rasteredge.com
HANDLE.NET (Ver. 8.1) Technical Manual 
Table of Contents 
1 Introduction
1.1 Handle Syntax
1.2 Architecture
1.2.1 Storage
1.2.2 Performance
1.3 Protocols and APIs
1.4 Authentication
1.4.1 Types of Authentication
1.4.2 Certification
1.4.3 Sessions
2 Upgrading an Existing Handle Server to Version 8.1
3 Installing and Running a Handle Server
3.1 Installing Java
3.2 Unpacking the Distribution
3.3 Choosing an Installation Directory
3.4 Running the Setup Program
3.5 Running the Handle Server for the First Time
3.5.1 Homing your prefix with the handle admin tool
3.6 How Your Prefix Was Set Up
3.7 Installation Directory
3.7.1 logs/access.log
3.7.2 logs/error.log
3.7.3 config.dct
3.7.4 siteinfo.json
3.7.5 bdbje/
3.7.6 replicationDb/
3.7.7 pubkey.bin, privkey.bin
3.7.8 delete_this_to_stop_server
3.7.9 txns/
3.7.10 txn_id
3.7.11 replpub.bin, replpriv.bin
3.7.12 txnstat.dct
3.7.13 admpub.bin, admpriv.bin
3.7.14 serverCertificate.pem, serverCertificatePrivateKey.bin
3.7.15 webapps, webapps-temp, webapps-storage
3.7.16 txnsrcsv.bin
3.7.17 siteinfo.bin
3.8 Client configuration
3.8.1 $HOME/.handle/bootstrap_handles
3.8.2 $HOME/.handle/root_info
3.8.3 $HOME/.handle/config.dct
control software system:How to C#: Generate Thumbnail for PowerPoint
Preview Document. Conversion. Convert PowerPoint to PDF. Convert PowerPoint to PowerPoint Pages. Annotate PowerPoint. Text Search. Insert Image. Thumbnail Create
www.rasteredge.com
control software system:How to C#: Generate Thumbnail for Raster
VB.NET How-to, VB.NET PDF, VB.NET Word, VB.NET Excel, VB.NET And generating thumbnail for Raster Image is an easy work. How to Create Thumbnail for Raster in C#.
www.rasteredge.com
HANDLE.NET (Ver. 8.1) Technical Manual 
3.9 Restarting a Handle Server
3.10 Inactive Prefixes
3.11 Splitting a Handle Server
4 Batch Operation – Command Line
4.1 Create Handle Batch Format
4.2 Delete Handle Batch Format
4.3 (Un)Home Prefix Batch Format
4.4 Add Handle Value Batch Format
4.5 Remove Handle Value Batch Format
4.6 Modify Handle Batch Format
4.7 Authentication Information Format
4.8 Session Setup Information Format
4.9 Handle Value Line Format
5 Advanced Server Configuration
5.1 The .dct file format
5.2 Top-Level Settings
5.3 hdl_udp_config, hdl_tcp_config, hdl_http_config
5.4 HTTP Configuration
5.4.1 Running an HTTP Proxy
5.5 server_config
5.6 log_save_config
5.7 Example config.dct File
5.8 Client configuration via $HOME/.handle/config.dct
6 Other Tools and Features
6.1 DBTool
6.2 DBList/DBRemove
6.3 Query Resolver
6.4 Test Tool
6.5 KeyUtil
6.6 GetSiteInfo
7 Replication
7.1 Setting up a Single Mirror Handle Server
7.2 Further Replication Configuration
7.2.1 Configuring the Transaction Sources
7.2.2 Authentication and Authorization
7.3 Multi-primary Replication
8 Using Custom Handle Storage
8.1 Using a SQL Database for Storage
8.1.1 Configuring the Handle Server
8.1.2 Example SQL Tables
8.1.3 Depositing Handles Outside the Handle Server
8.1.4 Using Custom SQL Statements
8.2 Using PostgreSQL Database
control software system:Create Thumbnail in Web Image Viewer | Online Tutorials
or Images; Create Thumbnail; Generate Barcodes on Your Documents; Read Barcodes from Your Documents. Multi-page Tiff Processing; RasterEdge OCR Engine; PDF Reading
www.rasteredge.com
control software system:Create Thumbnail Winforms | Online Tutorials
Create Thumbnail; Generate Barcodes on Your Documents; Read Barcodes from Your Documents. Multi-page Tiff Processing; RasterEdge OCR Engine; PDF Reading; Encode
www.rasteredge.com
HANDLE.NET (Ver. 8.1) Technical Manual 
9 Handle Clients & the Client Library (Java Version)
10 Configuring an Independent Handle Service
10.1 Client Configuration Details
10.2 Server Side Configuration
11 Template Handles
11.1 The Template Delimiter
11.2 Template construction
11.3 Template handles by reference
12 The 10320/loc Handle Value Type
13 Handle Server Backup
14 Handle HTTP JSON REST API
14.1 Resources
14.2 Requests
14.3 Cross-Origin Resource Sharing
14.4 Responses
14.5 Methods
14.5.1 GET /api/handles/{handle}
14.5.2 PUT /api/handles/{handle}
PUT /api/handles/{handle}?index={index}
14.5.3 DELETE /api/handles/{handle}
DELETE /api/handles/{handle}?index={index}
14.5.4 GET /api/handles?prefix={prefix}
14.6 Authentication
14.6.1 Handle-Based Certificates
14.6.2 Client-Side Certificates
14.6.3 Basic Access Authentication
14.6.4 Authentication via Authorization: Handle
14.6.5 Challenge from Server to Client
14.6.6 Challenge-Response Request from Client to Server
14.6.7 Further Requests in Session
14.6.8 Authenticating the Server
14.6.9 Deleting a Session
14.7 Sessions API
14.7.1 POST /api/sessions
14.7.2 GET /api/sessions/this
14.7.3 PUT /api/sessions/this
14.7.4 DELETE /api/sessions/this
14.8 JSON Representation of Handle Values
control software system:How to C#: Set Image Thumbnail in C#.NET
VB.NET How-to, VB.NET PDF, VB.NET Word, VB.NET Excel How to C#: Set Image Thumbnail in C#.NET. With XImage.Raster SDK library, you can create an image viewer and
www.rasteredge.com
control software system:How to C#: Generate Thumbnail for Excel
Preview Document. Conversion. Convert Excel to PDF. Convert Excel to HTML5. Insert Image. Thumbnail Create. Thumbnail Create. |. Home ›› XDoc.Excel ›› C# Excel
www.rasteredge.com
HANDLE.NET (Ver. 8.1) Technical Manual 
1 Introduction 
The Handle System is a comprehensive system for assigning, managing, and resolving persistent 
identifiers for digital objects and other resources on the Internet. The Handle System includes an open 
set of protocols, an identifier space, and an implementation of the protocols. The protocols enable a 
distributed computer system to store identifiers of digital resources and resolve those identifiers into 
the information necessary to locate and access the resources. This associated information can be 
changed as needed to reflect the current state of the identified resource without changing the 
identifier, thus allowing the name of the item to persist over changes of location and other state 
information.  
1.1 Handle Syntax 
Within the handle identifier space, every identifier consists of two parts: its prefix, and a unique local 
name under the prefix known as its suffix. The prefix and suffix are separated by the ASCII character 
"/". A handle may thus be defined as  
<Handle> ::= <Prefix> "/" <Handle Local Name>  
For example, handle "12345/hdl1" is defined under the Handle Prefix "12345", and its unique local 
name is "hdl1".  
Handles may consist of any printable characters from the Universal Character Set of ISO/IEC 10646, 
which is the exact character set defined by Unicode. The UCS character set encompasses most 
characters used in every major language written today. To allow compatibility with most of the 
existing systems and prevent ambiguity among different encoding, handle protocol mandates UTF-8 
to be the only encoding used for handles. The UTF-8 encoding preserves any ASCII encoded names, 
which allows maximum compatibility to existing systems without causing naming conflict. 
In general, handles are case sensitive. However, any handle service may define its identifier space 
such that all ASCII characters within any identifier are case insensitive. This is recommended and the 
default for Handle.Net server software. The Global Handle Registry® (GHR) guarantees that handles 
resolved from the GHR are case-insensitive. Note that case-insensitive handle services generally use 
ASCII case folding only; more general Unicode case folding and Unicode normalization should not 
generally be expected. 
The handle identifier space can be considered as a superset of many local identifier spaces, with each 
local identifier space having its own unique handle prefix. The prefix identifies the administrative unit 
of creation, although not necessarily continuing administration, of the associated handles. Each prefix 
is guaranteed to be globally unique within the Handle System. Any existing local identifier space can 
join the global handle identifier space by obtaining a unique prefix, with the resulting identifiers being 
a combination of prefix and local name as shown above. Every handle is then defined under a prefix. 
The collection of local names under a prefix is the local identifier space for that prefix. Any local name 
must be unique under its local identifier space. The uniqueness of a prefix and a local name under 
HANDLE.NET (Ver. 8.1) Technical Manual 
that prefix ensures that any identifier is globally unique within the context of the Handle System. 
Each prefix may have many derived prefixes registered underneath. A derived prefix is formed 
syntactically by appending "." followed by other characters (exception "/" and ".") to an existing 
prefix.  For instance prefix "10.1045" is derived from "10" and prefix "10.978.8896471" is derived from 
"10.978" which is derived from "10". In general derived prefixes need not be administratively related 
to the prefixes from which they are derived. 
1.2 Architecture 
The Handle System has two physical levels of hierarchy, the root service (also known as the Global 
Handle Registry®) and local services. Local handle services contain the handle records under a specific 
prefix. Whereas the root service contains handle records that describe who controls which prefixes 
and how to reach the local handle services for specific prefixes.  
A handle service can be composed of one or more sites. Sites can be primary or mirror. Mirror sites 
replicate the handle records stored on the primary sites. Typically a service has a single primary, but it 
is possible to have a service with multiple primaries which then replicate from each other. Replication 
as implemented in the Handle.Net software offers eventual consistency. 
Typically there is a one-to-one relationship between a site and a handle server. It is however possible 
to have multiple handles servers in a site. In this case the handle data for the site is partitioned across 
the handle servers in the site. Having multiple handle servers in a single site is unusual though it can 
be desirable if you have more handle records than can be managed by a single handle server.  
Resolution is performed by first querying the root handle service for the service handle record 
pertaining to the prefix. This prefix handle is constructed using the syntax 0.NA/<prefix>.  The 
1
returned handle record will contain one or more HS_SITE handle value. These handle values describe 
1 0.NA derives from "naming authority", an obsolete term for "prefix". 
HANDLE.NET (Ver. 8.1) Technical Manual 
how to reach the sites that make up the local handle service for that prefix. The resolver selects a site 
and then sends it a resolution request for the desired handle record. 
It is also possible to have prefixes delegated from the GHR to local handle services. In this scenario, 
the prefix handle records for all prefixes derived from a given prefix P are resolved and administered 
at a local handle service defined by HS_SITE.PREFIX handle values in the prefix handle record for P. 
This allows the possibility of additional levels of hierarchy in the prefix resolution process. 
1.2.1 Storage  
The Handle System has been designed at a very basic level as a distributed system; that is, it will run 
across as many computers as are required to provide the desired functionality.  
Handles are held in and resolved by handle servers and the handle servers are grouped into one or 
more handle sites within each handle service. There are no design limits on the total number of 
handle services which constitute the Handle System, there are no design limits on the number of sites 
which make up each service, and there are no limits on the number of servers which make up each 
site. Replication by site, within a handle service, does not require that each site contain the same 
number of servers; that is, while each site will have the same replicated set of handles, each site may 
allocate that set of handles across a different number of servers. Thus, increased numbers of handles 
within a site can be accommodated by adding additional servers, either on the same or additional 
computers, additional sites can be added to a handle service at any time, and additional handle 
services can be created. Every service must be registered with the Global Handle Registry, but that 
handle service can also have as many sites with as many servers as needed. The result is that the 
number of identifiers that can be accommodated in the current Handle System is limited only by the 
number of computers available.  
1.2.2 Performance  
Constant performance across increasing numbers of identifiers is addressed by replication, caching 
and hashing.  
The individual handle services within the Handle System each consist of one or more handle service 
sites, where each site replicates the complete individual handle service, at least for the purposes of 
handle resolution. Thus, increased demand on a given handle service can be met with additional sites, 
and increased demand on a given site can be met with additional servers. This allows for clients to 
optimize resolution performance by selecting the "best" site from a group of replicated sites.  
Caching may also be used to improve performance and reduce the possibility of bottleneck situations 
in the Handle System, as is the case in many distributed systems. The Handle System data model and 
protocol design includes a space for cache time-to-live values.  
Hashing is used in the Handle System to evenly allocate any number of identifiers across any number 
of servers within a site, and allows a single computation to determine on which server within a set of 
servers a given handle is located, regardless of the number of handles or the number of servers. Each 
HANDLE.NET (Ver. 8.1) Technical Manual 
server within a site is responsible for a subset of handles managed by that site. Given a specific 
identifier and knowledge of the handle service responsible for that identifier, a handle client selects a 
site within that handle service and performs a single computation on the handle to determine which 
server within the site contains the handle. The result of the computation becomes a pointer into a 
hash table, which is unique to each handle site and can be thought of as a map of the given site, 
mapping which handles belong to which servers. The computation is independent of the number of 
servers and handles, and it will not take a client any longer to locate and query the correct server for a 
handle within a handle service that contains billions of handles and hundreds of servers, than for a 
handle service that contains only millions of handles and only a few servers.  
1.3 Protocols and APIs 
A single handle server typically opens three network listeners, on port 2641 UDP, port 2641 TCP, and 
port 8000 TCP.  This can be changed in configuration (the config.dct and siteinfo.json files, see 
Chapter 5) as well as in the HS_SITE values of prefix handles that refer to the handle server.  
Port 2641 (UDP and TCP) is the IANA-assigned port number for the Handle wire protocol.  The Handle 
service model and wire protocol are described in RFC 3650, RFC 3651, and RFC 3652.  Handle clients 
generally will try to use 2641 UDP for resolution requests, which provides optimum performance in 
typical scenarios.  TCP is generally required for administrative requests, and is used as a fallback for 
resolution when UDP is slow or unavailable. 
Port 8000 offers an HTTP and HTTPS interface.  Handle servers (from Handle.Net software version 8) 
use "port unification" so that HTTP and HTTPS are available over the same port.  If the standard 
Handle protocol ports are not available, Handle clients may fall back to tunneling the Handle wire 
protocol over HTTP.  Additionally (from Handle.Net software version 8) Handle servers offer a 
JSON-based HTTP API using many RESTful principles over this interface; see Chapter 14.  Finally, 
Handle servers incorporate a modular extension framework in the form of a Java servlet container. 
Java servlet web-apps can be added to the Handle server and can optionally provide a browser-based 
UI accessible over the HTTP interface.  
The Handle.Net software distribution comes with a browser-based administrative client, "admin.war", 
which could be accessed at https://IP-ADDRESS:8000/admin/
, where the IP address should be the 
public address from siteinfo.json.  Note that even though it is accessible through the Handle server as 
a convenience, this is a pure client, which talks to the handle server over its public HTTP API, and 
could in principle run anywhere. 
The Handle.Net distribution comes with GUI client applications and command-line clients to perform 
Handle operations; see the Handle Tool User Manual
and Chapter 4, Batch Operation
 These tools use 
the Java Handle client library which comes with the Handle.Net software; the Java Handle client 
library accesses Handle servers using the Handle wire protocol.  Users are encouraged to develop 
their own client tools using the Java Handle client library.  There are not maintained client libraries for 
other development environments than Java; developers using other languages may prefer to use the 
HANDLE.NET (Ver. 8.1) Technical Manual 
Handle HTTP API to communicate with Handle servers. 
1.4 Authentication 
The current distribution of the Handle.Net software uses the Java standard cryptography libraries for 
low-level cryptography routines. 
In order to authenticate, a user needs to have a handle identity. A handle identity is either a public 
key or secret key stored on a handle record. This identity is expressed as a string defining the index of 
the value that contains the key separated from the handle by a colon. For example if you had a public 
key stored at index 300 on handle 12345/abc the authentication identity would be "300:12345/abc". 
When you register a prefix a prefix handle is created on the root service and your public key is stored 
on that handle at index 300. As such it is typical for handle users to have a handle identity of the form: 
300:0.NA/<prefix> 
Since the prefix handle 0.NA/<prefix> is under the control of GHR administrators rather than the LHS 
administrators, many users will find it more useful to have administrators on handles under their 
prefix.  There could either be multiple handles, or multiple indexes in one handle, for instance 
300:12345/ADMIN1 
300:12345/ADMIN2 
or 
300:12345/ADMIN 
301:12345/ADMIN 
The index in a handle identity is generally a positive integer, but the special value 0 indicates that the 
user's public key or secret key is stored at some unspecified index. Tools can use this to allow handle 
identities which are effectively just handles rather than index:handle pairs. If such an unindexed 
handle identity is referenced for authorization, any index will be considered authorized; if a client 
authenticates using an unindexed handle identity, then the client will be authorized to perform 
operations allowed to the unindexed identity but also, in the case of public key authentication, 
operations allowed to the identity using an actual index with the correct public key.  (For secret key 
authentication the server may not be able to determine the "actual" index so only the unindexed 
authorization holds.) This feature is supported starting in Handle.Net software version 8. 
1.4.1 Types of Authentication  
The Handle System provides two forms of authentication: public key and secret key.  
In the current implementation, public key authentication is performed using the DSA or RSA 
algorithm. DSA generally uses a key length of 1024 bits; RSA allows a key length variable from 1024 to 
4096 bits or higher, and can be chosen by the user when generating keys. The Handle.Net software 
10 
Documents you may be interested
Documents you may be interested