Current Registration Operation

As already indicated, in the current specification of the Handle protocol, new Handle Records are registered by means of theOC CREATE HANDLEoperation. Note that this operation also enables to overwrite (update) existing Handle Records, which is achieved by a particular flag denoted as MSG FLAG OVRW. This flag is contained in the Message Envelope.

The actual content for this operation is contained in the message body, for which a particular serialization structure is defined, as shown in the following subsection. Note that the serialized representation is necessary to carry out the message transmission within the particular network.

5.4.3.1 Message Body Serialization

INT <handle> INT <handleValues>

Figure 5.7: Serialized Message Body of already built-inOC CREATE HANDLErequest.

The serialized representation of the corresponding message body is depicted in Figure 5.7. This representation describes the message body as a bit-stream representation used to specify the en-coding/decoding procedure within the receiving end (client / Handle server). Each black INT field denotes a 4-byte unsigned integer, which are used to specify the number of elements to be read from the following field. For the<handle> field, it determines the number of characters,

INT_1

<ts> INT <type> INT <data> INT

<refs>

Figure 5.8: Already implemented Handle Value serialization.

which form the Handle-PID. Whereas for the<handleValues>field, it specifies the number of Handle Values, which are transmitted with the message body. Each individual Handle Value itself, is encoded according to the serialization scheme depicted in Figure 5.8.

In contrast to the black fields, the whiteINTfields, denote 4-byte unsigned integers, which contain values specific to the respective Handle Values fields. Note that aINT 1field occupies only one byte of memory.

The<type>,<data>and<handle>fields are each preceded by a 4-byte unsigned integer speci-fying the number of the contained elements composing the respective content.

With this structure, the message is sent to the primary Handle server.

5.4.3.2 Server-Side Registration Algorithm

When the primary Handle server receives a message submitted by a client, the message body is decoded back based on the information contained in the message header. In the case of a OC CREATE HANDLEoperation, the message body is decoded according to the serialization scheme described in the previous subsection resulting a Handle-PID and a set of Handle Values. The message decoding procedure is then followed by the internal registration procedure.

As illustrated in Figure 5.9, the overall registration algorithm includes several steps. The thicker black lines represent the main path, which is executed for an ordinary successful Handle Record registration. The black boxes, ”Insert Transaction ID” and ”Write To Database”, represent the most important steps of the entire registration algorithm.

These black boxes are usually also the most expensive steps in the registration algorithm within the primary Handle server. In each of these steps, a transactional operation is performed. In step ”In-sert Transaction ID”, certain information is written transactionally to an internal database used to ensure the replication system to be provisioned appropriately, including the increase of the previ-ously explained counter tracking the number of all so far accomplished administration operations (cf. Section 5.4.2,OC GET NEXT TXN ID). In step ”Write To Database”, the actual Handle Values are finally persistently stored into the attached main database.

Therefore, these steps are often responsible for a significant performance loss of the overall regis-tration algorithm, which is then ultimately propagated to the registrants.

However, also the green box, ”User Authorization”, can often be considered as a performance-relevant step. In this step the authorization process is executed. The internal algorithm of this process is dedicatedly depicted in Figure 5.10.

Depending on the implemented authorization scheme, it might cause a considerable overhead in the overall registration algorithm.

The authorization procedure in the Handle System always starts with the prefix Handle Record.

The prefix Handle Record is queried in order to determine the authorized users, which are specified byHS ADMIN-typed Handle Values. As an example, the prefix Handle-PID of the TextGrid repos-itory is0.NA/21.11113, with the corresponding prefix Handle Record depicted in Figure 5.11.

As can be seen (grey Handle Values), for the TextGrid prefix there are four groups of permitted

Arrived Request

OpCode=100 determine OpCode

[Yes]

[No]

User is Authenticated

Handle Already Existing getAdminInfo

Lock(Handle)

Force Overwrite Flag is Set

[Yes]

Is User Authorized User Authorization

Insert Transaction ID

Write To Database

Unlock(Handle)

[Yes]

response (INVAILD_ADMIN)

send response

[No]

[Yes]

response (HANDLE_ALREADY

_EXISTS)

[No]

User Authentication [No]

response (SUCCESS) doCreateHandle()

OC_RETRIEVE_TXN_LOG

Figure 5.9: Algorithm forOC CREATE HANDLEoperation, which is already implemented into Han-dle servers.

users. One of these is the group listed in the21.11113/USERLIST-Handle Record (Handle Value with index=102 in TextGrid prefix).

The list of permitted users is retrieved prior to the actual authorization process at the step repre-sented by the yellow box, ”getAdminInfo” (cf. Figure 5.9). This list is then used in the authoriza-tion process, green box, to determine whether the (authenticated) user is also a member of the set of authorized users.

However, exactly this process can cause a considerable overhead in the registration procedure, based on additional resolution queries as explained by the following two paragraphs:

Administrative User: Often, a Handle Record managing user is also an administrator of the Handle server itself. Such a user is directly authorized by a configuration file (config.dct) of the Handle server. The authorization workflow of this user concept is represented by the thicker black lines in Figure 5.10.

Non-Administrative User: Another concept is to authorize users based on individual Handle Records allowing to establish a hierarchy among the managing users. However, the disad-vantage of this concept is that they entail additional resolution queries against the Handle server, which finally involve additional load on the attached main database. This is repre-sented by the blue paths in Figure 5.10. As we have already seen in the previous chapter, an increased request population at a component can easily lead to an increased processing time of the component. This user concept, therefore, leads to more load at the database of the Handle server, which finally could cause a further increase of the overall response time.

Ultimately, when all the steps of the registration algorithm, including the authorization procedure, are accomplished, the Handle Record finally becomes registered or updated.

Inspired by the principles behind the original registration operation, in the following subsections, we finally provide our bulk operation extension for the Handle protocol.