Device Interconnect Protocol DIP is the backbone of the NoTA architecture. Each subsystem needs to implement the DIP stack. The DIP consists of High Interconnect (H_IN) and Low Interconnet (L_IN). DIP can be implemented for very different types of physical interconnects, from ASIC internal interfaces to device external interfaces, from wireless to wired. The physical interconnect is fully abstracted from the DIP user.
L_IN provides uniform socket based communication mechanism between any two network endpoints. Sockets can be used either in connection-oriented (CO) or connection-less (CL) modes. Broadcast and multicast communication means in typical sense are not supported. Both socket modes are reliable. Message borders are not maintained in either case.
L_IN is also responsible for resolving its own Interconnect Address (IA) as well as IA of the network resource manager. In case of dynamic network environments, L_IN needs to be able to detect disconnection from network.
Internally L_IN is divided into two layers, namely L_INup and L_INdown. The former handles all uniform transport independent protocols, while the later implements transport network dependent protocols. L_INdown provides also socket based interface but instead of Interconnect Address (IA), it handles network specific address/access information structures. L_INdown needs to be ported to a specific physical interface.
L_IN is responsible for connecting the subsystems together whereas H_IN handles service registration, discovery, access and security. H_IN uses the L_IN though the L interface (L_IF).
The Application and Service Nodes (ANs and SNs) use the H_IN through the H interface (H_IF). The reference implementation of the DIP stack is based on BSD Socket API. The modified BSD Socket API prefixes each function with capital H and adds instance. For example connect(args) function call is modified to be Hconnect(h_in_t* h_in, args) function call. The arguments, return values and semantics are exactly the same as in BSD Socket API. There is also an API extension that adds some functions to BSD Socket API. Usage of the API Extension is never compulsory.
H_IN provides streaming type and message based sockets. The streaming type socket does not preserve message boundaries whereas the packet type socket preserves the boundaries. Otherwise there is no differences in sockets types.
The services can have multiple ports when they register. Port 0 refers to standard port that typically accepts service requests. The Service Node (SN) may allocate other ports to whatever purposes. Any port can support either message based or streaming based sockets.
The service repository in H_IN is centralized. One of the H_INs within the device acts as a HManager. This special node is responsible for keeping a list of the services in the network and acting as an authorization entity. HManager resolves the Service ID (SID) to Interconnect Address (IA).
Service Level Resource Manager (also called RMSN) is a node in the system. The ANs and SNs communicate with RMSN using the H_IF. The RMSN allocates Service IDs (SID) based on service naming ontologies to services when they register themselves to the RMSN. Respectively, service user can query the Service ID (SID) from the RMSN based on the service name.
