The D16 project core is an open-source (Licensed under
GPL GNU GENERAL PUBLIC LICENCE), multi-platform (currently Win32 and Linux),
peer-to-peer distributed computing platform. According
Distributed computing is the process of aggregating the power of several
computing entities to collaboratively run a single computational task
in a transparent and coherent way, so that they appear as a single, centralized
The D16 core project - Core architecture
version-1.0. Document revision-1.0-
version 1.0 of the core design and architecture of the D16 core project is explained
here. Please note that this document is preliminary and is subject to changes
partially or wholly, as the design and/or architecture of the project changes.
A PDF version of this document can be found in the Documents
section along with other project documents. For displaying these documents
you may need Adobe Acrobat reader.
The D16 core project consists of (at least)the following components
The D16 tracker server.
each of which is explained below.
The D16 tracker server
The Basic architecture is illustrated below with the help of following diagram.
As shown in the diagram, the D16 network consists of a tracker server running D16 core tracker server software, and various peers (which can be home or work PCs, work-stations, main-frames, or even other types of dedicated servers) running the D16 core peer platform software.
All the network activities are made according to the D16 protocol which is a high level protocol layer laid upon the TCP/IP. In D16 protocol every transaction is made using so-called D16 signals, which has mainly three fields. More information on the D16 protocol can be found here.
The peers initially connects to a tracker server whose address is known (which is configurable on the peer platform itself), and sends a registration signal. If the registration signal is accepted, the tracker server enrolls the peer to the peer-list it is maintaining, and sends back an ACCEPT signal indicating the registration was accepted; on the other hand when the registration is rejected, a DECLINE signal is send back.
Another function of the tracker server is to maintain a list of peers currently connected to the network (which may be sorted according to maximum processing power that can be offered, resource contribution and/or connection type/bandwidth). This list is supplied to each registered peer upon request. For a tight network such as clusters and or grids, this operation is comparatively easy and straight forward. But maintaining such a list becomes a tedious process on a loose bound Internet network or on a WAN, where most of the individual peers are not guaranteed to stay connected all the time, or for at least by the time of completion of the distributed tasks; more over they may disconnect from the network unexpectedly, without reporting a DISCONNECT signal to the tracker server. Which in turn causes the tracker server to keep such non-existing peers, enrolled to the peer-list they are maintaining. However this problem can be resolved by accepting a connection error report from other peers as they encounter a connection error with any peer, so that the tracker server can check the connection and remove the entry corresponding to the particular peer, if necessary.
In short the D16 tracker server is a server application which facilitates the following:-
Handling of registration/disconnection of peers.
The D16 Network protocol
The D16 network uses D16 protocol – which is a high-level protocol laid upon TCP/IP. D16 protocol uses D16 signals for transmission of control and data. Signals are defined for various purposes (all signals are predefined). A signal has the following structure.
A signal is constituted of fields (normally four in number).
A Tag field
-Which specifies the class and type of signal. The class of signal may be one of the predefined classes specified in appendix A. Type of the signal is one of the types specified in appendix A, which specifies what type of action does the signal mean. The two fields are separated by a tag separator (specified in appendix B Constants and symbols used).
<Signal CLASS><tag sep><Signal TYPE>
An ID field
-An ID field follows the tag field, which has the information about the peer who sends the signal. It has three parts separated by tag separators in between.
<IP address><tag sep><Port number><tag sep><Display Name>
-Signal body field is the body of the signal. Contains extra data or information, if any, required by the signal. This has only one part and there is no restriction for the internal part of this field. Also there is no restriction on the length of data in this field.
-The signal is terminated by an EOT byte. This field is only one byte in length and contains an EOT character(may differ from an ASCII EOT. Specified in appendix B Constants and symbols used), to indicate that the signal is terminated.
Every field is separated by a field separator (specified in appendix B Constants and symbols used).
The D16 Intermediate Transaction Layer (ITL)
This is the most important part of a peer platform, which connects to the tracker servers and to other peer and communicates with them according to the D16 protocol. The ITL is a program which runs on each peers and performs registration/disconnection and other transactions with the tracker server and other peers. The main job of ITL is to provide manageable services, in the form of various objects, to the D-Script Virtual Machine (DVM), so that the distributed scripts and libraries can make use of them.
D-Script Virtual Machine (DVM)
The D16 network protocol
© 2004 The D16 project team. All rights reserved.
Site designed and maintained by HK a.k.a. eXeption