> developer
Virtual Resources

Virtual Resources

Standards are the lifeblood of information technology and innovation. Some technical standards require participants to register their use and implementation of the standard's virtual resources. Novell has introduced many standards for the Novell environment which include virtual resources.

Types of Virtual Resources

  Directory OID/Prefix
  NMAS Method
  Novell Audit Application Identifier
  NLM Name Prefix
  IPX/SAP Service Type (Bindery Object Types)
  IPX Static Socket Numbers
  NCP Extension
Directory OID/Prefix

Novell eDirectory™ is a name service derived from the X.500 standard and is an object oriented, hierarchical, distributed, and replicated database. One feature of the directory is the ability to extend the types of objects that can be stored in the directory schema. By default many types of objects are available in the pre-defined base schema. However, developers may also add class and attribute (data element) definitions to the base schema, called schema extensions. Each schema class or attribute must have a unique OID. An OID is a hierarchical identifier with periods separating each level. OIDs are read from left to right with the first value being the root. The value that follows is a sub-authority of the root. In most schema extension scenarios, all OIDs have the same base value with the trailing value rendering it unique. Software developers, for example, obtain a base OID to which they append values, creating their own unique OIDs.

Names should comply with LDAP conventions which allow only alpha-numeric characters and a single - character. In addition, the first character must be an alphabetic character. Delimiter characters such as space, underscore and colon should not be used. LDAP also requires the use of a valid OID or ASN1 ID with each class or attribute definition. In order to allow developers to define as many schema extensions as they need through the development and production environments, and ensure that the schema names are unique, developers should visit one of the online schema registries which register name prefixes, and can assign a unique sub-arc ASN1 ID if needed. Name prefixes are used by developers after they are registered to uniquely identify schema extensions. Name prefixes may consist of up to 12 alpha or numeric characters and should begin each schema extension name.

Example: WidgetMakers, Inc. registers "awidget" as a schema name prefix. Should they define a new slidingWindow class, they would define the new class name as awidgetSlidingWindow, using mixed case to make the name more readable, and assign it an ASN1 ID which begins with the assigned sub-arc and is uniquely numbered after the sub-arc. If an additional attribute type of slider were defined it would need a unique name as well, and could be defined as awidgetSlider and also given a unique ANS1 ID. No attribute or class may have the same name or ASN1 ID, as they are stored in the same domain and indexed via their name and ASN1 ID.

Most directory servers will allow you to specify an alpha-numeric name for an OID number. If WidgetMakers, Inc. hadn't registered for an OID, they may have assigned the "awidgetSlidingWindow" attribute an OID of "awidgetSlidingWindow-oid". It's unique, and as such serves the purpose.

Even though you may not need to register your own OID, it's still a good idea. LDAP attributes, syntax definitions, and object classes all use OIDs. So do SNMP and other protocols that support the ANSI unified identification scheme.

Get more information on Directory OID/Prefix registration.

Advantages

Your extensions won't be in conflict with other registered extensions. Also, you are assured of a valid and unique OID.

Disadvantages

Changes to the directory schema are not always easily removed. Attributes can only be removed if they are not used in a class definition. If you add attributes to Novell base classes, you will not be able to remove them. Classes can be removed as long as there are no objects instantiated of that class type. The Novell base schema cannot be removed.

Registration

Novell no longer maintains a vendor-accessible Directory OID/Prefix Registry to generate Class and an Attribute OIDs based on Novell’s address space. Vendors can obtain a base OID directly from any ISO Name Registration Authority. We encourage you to search the Internet for a complete list of selections. Some examples include:

You can also research current OID registrations from the Alvestrand OID lookup service.

NMAS Method
Login Service Methods (LSMs) must be digitally signed to operate under the NMAS framework. In order to sign a method you must use the Novell-supplied signing tools to generate a csr.ber file.

Send the generated file csr.ber to the email address devsup@novell.com - the subject line of the email should include the following wording: "Register Virtual Resource".

After submitting your csr.ber file to Novell, please complete the online registration form. Once you have completed the registration form and clicked on the Submit button, the information you entered will be emailed to Novell and the registration information matched with your submitted csr.ber file - Novell will then email you two files: cert.ber, which is your signed certificate, and mib.ber, your module identification block. You will use these two files during the module signing process described in the NMAS Login Method Developer Manual, section 3.3.2.

Registration

Register an NMAS Method

Novell Audit Application Identifier
Novell Audit is a centralized auditing service that is designed to be leveraged by numerous applications as a centralized secure logging repository. In addition to logging events, the service will provide extensive real-time monitoring, notification and reporting capabilities.

The Novell Audit Application Identifier (AppID) is required for any application that wishes to use any of the Novell Audit event reporting Interfaces (C/C++, Java and Visual Basic).

Registration

Register an Novell Audit Application Identifier

NLM Name Prefix

NetWare Loadable Modules (NLMs) are executable applications that run in the NetWare Operating System environment. NetWare requires NLMs to have unique names. If two engineers each develop an NLM and by chance they each give their NLM the same name, NetWare will allow only one of these NLMs to be loaded at a time. Likewise, the NetWare symbol table cannot contain two symbols with the same name. An NLM fails to load when it attempts to export a symbol that is already listed in the symbol table.

Obviously, engineers do not know what their peer's NLMs will be named, nor do they know what symbol names (functions and variables) these NLMs will export.

To address this issue, NLM developers can register an NLM Name Prefix with Novell to ensure that they have unique title in the NetWare NLM environment. This prefix is used in the module name and appended to the beginning of each exported symbol (by the NLM linker) with the '@' character separating the prefix from the name.

Advantages

Registering your NLM Name Prefix will reduce the risk of NLM name conflicts with other NLM developers.

Disadvantages

Not all developers register or use an NLM Name Prefix with Novell. Therefore, end-users may still discover conflicts.

Registration

Register an NLM Prefix Name

IPX/SAP Service Type (Bindery Object Types)

The IPX protocol includes the Service Advertising Protocol (or SAP). SAP makes the process of adding and removing services on an IPX internetwork dynamic. As servers are booted up, they may advertise their services using SAP; when they are brought down, they use SAP to indicate that their services will no longer be available. IPX network servers may use SAP to identify themselves by name and service type. All entities that use SAP must broadcast a name and Service Type that (together) are unique throughout the entire IPX internetwork. This policy is enforced by system administrators and application developers.

Resource Description and Parameters

An IPX/SAP Service Type is a 2-byte value that uniquely identifies a specific class of IPX service. Service types may include print servers, database servers, archive servers, etc.

Resource applicants may choose to make their assigned type public or private. The list of public Service Types is published quarterly by Novell. (See NDEVSUP; Library 14 (LAN Protocols); DSAP1?.EXE)

Resource applicants can apply for an IPX/SAP Service Type by submitting the following information to Novell:

  • Applicants "Personal Identification Number" (PIN) as assigned by Novell Services & Support.
  • The name, company, address and phone number of the official contact of this resource. (Novell must be informed of changes to this information).
  • The name of the product (or Server Application) to which this resource will be applied.
  • Justification for allocation of this resource which might include; why this application must "live" at the IPX layer and why NDS is not suitable.

Advantages

SAP is a well established component of the IPX protocol definition and is supported by all certified IPX routers. It is ideal for applications that "live" in the IPX environment.

Disadvantages

SAP traffic can be burdensome for specific IPX environments. Large IPX internetworks which are connected by relatively slow links can be overcome by SAP traffic. There are several solutions to this problem:

  • Novell introduced the NLSP protocol in order to minimize SAP traffic in an IPX network.
  • Novell and other router vendors have introduced "SAP Filtering". This feature allows router administrators to restrict the distribution of SAP traffic by SAP Type and/or Server Name.

Obviously, the latter solution requires a well educated router administrator in order to be implemented effectively. Wise router administrators will look at the type of SAP traffic which exists on the network and filter selectively. Less purscapatious router administrators simply restrict all SAP traffic except selected Server name/types.

Alternatives

Only server applications that "live" in the IPX protocol layer need to SAP. Novell's Directory Services (NDS) offers higher level server applications a very productive and efficient alternative to SAP.

Registration

Register an IPX/SAP Service Type

IPX Static Socket Numbers

The IPX protocol addresses packets in a Network:Node:Socket format. The Network field of an IPX address contains value that represents a logical IPX network segment. This value is assigned to the IPX network segment by the network administrator and must be unique throughout the entire IPX internetwork. The Node field of an IPX address contains a value that represents a logical node on an IPX network segment. This value is generally a number that is 'burned' into the Network Interface Adaptor (NIC) at the factory. The Socket field of an IPX address contains a value that represents a logical process within the node. This value is generally obtained by an IPX application dynamically using the IPXOpenSocket() function. Novell also administers a list of IPX sockets that are "well-known" in all IPX network environments. "Well-known" or "Static" IPX sockets are a virtual resource which is assigned to qualified applications by Novell.

Resource Description and Parameters

An IPX Static Socket is a 2-byte value that is uniquely assigned to an IPX application.

Resource applicants may choose to make their assigned socket public or private. The list of public IPX Static Sockets is published quarterly by Novell. (See NDEVSUP; Library 14 (LAN Protocols); DSOC1?.EXE)

Resource applicants can apply for an IPX Static Socket by submitting the following information to Novell:

  • Applicants "Personal Identification Number" (PIN) as assigned by Novell Services & Support.
  • The name, company, address and phone number of the official contact of this resource. (Novell must be informed of changes to this information).
  • The name of the product (or Server Application) to which this resource will be applied.
  • Justification for allocation of this resource which might include; why this application cannot use a dynamic IPX socket.

Advantages

Some IPX server applications send identical information to multiple nodes. In such cases, it is more efficient to send one broadcast packet rather than sending multiple packets "point-to-point". Static sockets are used by such applications as broadcast sockets.

Disadvantages

IPX Broadcast packets will not cross and IPX router and are therefore limited to one logical IPX network segment. This limitation can be overcome by implementing "IPX directed broadcasts".

The IPXOpenSocket() function will allow a given socket number to be opened by only one caller. The socket must be closed by the original caller before it may be re-opened by another IPXOpenSocket() caller. Therefore, applications which use static sockets limit themselves to one executable instance of the application per IPX node.

Packets which implement static sockets can be filtered by IPX routers. Some IPX network administrators implement such filtering to limit the amount of IPX broadcasts on a logical IPX network segments.

Alternatives

Novell strongly encourages developers to implement dynamically assigned sockets where possible. [For more information on Static vs Dynamic Sockets, see BULLETS November 1994, Page 6 "Static vs. Dynamic IPX Sockets" --Mark Oberg]

Registration

Register an IPX Static Socket Number

NCP Extensions

NetWare file server services are access by NetWare clients via the NetWare Core Protocol (NCP). NCP defines the structure of packets used to communicate between the NetWare Client and the NetWare file server. Novell may (and generally does) introduce new NCPs with each release of NetWare. At the request of Novell's developers, NetWare was modified so that new NCPs could be introduced by developers outside Novell. This class of NCP is called NCP Extensions. Developers write NCP extensions by calling NWRegisterNCPExtension(), which requires a unique NCP Extension Name, and assigns a dynamic NCP Extension ID. Developers can also use NWRegisterNCPExtensionByID() which requires a unique NCP extension name and a unique NCP Extension ID. NCP Extension Names and IDs are registered with and assigned by Novell.

Registration

Register an NCP Extension