WARNING: This server provides a static reference view of the NetKernel documentation. Links to dynamic content do not work. For the best experience we recommend you install NetKernel and view the documentation in the live system .

Design Intent

NetKernel Prototcol (NKP) is designed to transparently relay requests between NetKernel instances.

The key design consideration is that NetKernel's ROC abstraction is distributed such that spaces on the server side are transparently "projected" into the client's address space. Conceptually one can think of NKP as providing the remote equivalent of the local standard module's import capability.

Physical Design

The diagram below shows the essential physical relations of NKP. Host1 wishes to make requests to a space hosted on a second NetKernel host2. Host2 instantiates an instance of the NKP Server endpoint in the target Server Space. Host1 instantiates an NKP Client endpoint in the Client Space which wishes to connect to the Server Space.

image/svg+xml Client Space NKP Client Host 1 Server Space NKP Server Host 2 SEP

Logical Design

Having physically connected an NKP Client to an NKP Server the ROC address spaces of the client and server spaces are logically unified. Any endpoints present in the Server Space are transparently projected to the Client Space. In the diagram below we see that the server side endpoint (SEP) is logically present in the Client Side space. (We have used a dotted boundary to indicate that this is a logical endpoint and requests to it are mediated by NKP).

image/svg+xml Client Space Host 1 SEP Server Space Host 2 SEP

A request made in the Client Space is resolved against the projected endpoints just as though they were local. When a projected client-side logical endpoint resolves the request, the physical request is transparently serialized over the NKP connection and issued to the server side physical endpoint in the Server Space.

The response from the SEP is transparently serialized over the NKP connection and returned to the Client-side requestor.

It should be apparent that, from the application architect perspective, NKP transparently bridges the ROC abstraction making it continuously span physical machines.


Requests transfered over NKP are full ROC requests and support the full capabilities of a local request including identifiers, verbs, request headers, primary arguments etc. However, due to the necessity of the physical network transfer there are some serializability considerations which arise, notably for representations and headers. These are discussed here.

Significantly, requests relayed over NKP transparently bridge the ROC request scope. This has very powerful consequences as will be shown below.


As with requests, the response is transparently relayed over NKP. One must be aware of the serializability considerations for the resource representation returned by a remotely invoked endpoint.

Significantly, response expiry determinants are preserved across NKP and so client-side resource representations computed with remote NKP endpoints may be cached with the full richness of the NK/ROC dependency model.

Request Scope

It was briefly mentioned above that NKP preserves the ROC request scope. NKP therefore allows sub-requests from remote endpoints to be resolved back into the client-side address space (the superstack). Just as with any local ROC request, the context for the invoked endpoint includes the resources of the requestor's (client side) address spaces...

image/svg+xml Client Space Host 1 SEP Server Space Host 2 SEP Superstack Request

By transparently bridging the ROC request scope, it should be clear that NKP enables rich bi-directional application patterns that span physical servers, in the same way that ROC enables rich spatial architectures within local address spaces.

As with any great power, there are also responsibilities. A detailed discussion of the design/security considerations of permitting server-side access to the full client-side request scope are discussed here.

Client Modes - Bridge vs One-shot

An NKP Server is a transport that allows requests to be made to the endpoints present in the server-side's address space.

In contrast, the client-side may choose two modes for connecting to the NKP server.


The bridge pattern enables a client to transparently import the remote server's address space by instantiating an NKP client endpoint with a dynamic configuration specifying the server connection details. In some ways this is similar to an NFS or Samba filesystem mount but, as has been shown above, it generalizes from files to the full ROC domain model.


One shot offers a generalization of HTTP/REST's ad hoc request model to the full ROC domain. In this mode a client application may instantaneously issue requests to a remote NKP server space either by using the full active:NKPRequest accessor (with full request capability) or with its simplified nkp:// scheme.

Connection Efficiency

Each of the bridge and oneshot modes share the same core foundation and provide robust and efficient connection cost minimization including keep alives, connection pooling and asynchronous (threadless) connections.

Since they are equally efficient your choice of client mode can focus on the architectural requirements of your solution.