...
Atomic messaging in simple operations
Operation An operation is defined as the communication that takes place in order to make an operation on the bit repository. Examples are get and put of data.
Operations must be as simple as possible, based on . They will be based on simple message primitives and data transmission. A primitive is a single request message to the system and the following replies. The primitives are defined on basis of atomic weldefined messages. This serves to give simplicity, and to get as little overlap between different operations as possible.
Operations are seen as a sequences of messages which collectively correspond to a full operation. For example the Get operation consists of a sequence of 5 messages as illustrated below. Note that it is divided, since the GetTime part An example of the Get operation is given in the below figure.
Here the full communication will result in an operation. The message communication is divided into two parts, each representing a primitive (identification of pillars and the actual get).
Note that the primitive for identification of pillars can cover request to several pillars, while the Get primitive for the actual get part only concern concerns one pillar.
Note also that the actual data transmission is not included here although it will be part of a full operation.
The Get operation can begin by asking pillars who will be the fastest, or it can start by actually sending a get message for a specific default pillar.
In the strict interpretation of single operations this will be seen as two operations
- GetTime
- Get
The difference between the two get scenarios will be that the first will both consist of a GetTime and a Get operation, while the later will only consist of a Getthere can be a number of different reponses, in cases where the pillar want to give information of the progress of the ioperation at pillar level. This can for instance be interesting for DVD pillars where there are several possibly time consuming phases in finding the data - even more so for a put operation.
Conversation Id
We generate a unique conversation id at initiation of a conversation such that it is possible to identify which conversation a message belongs to.
Reuse and overlap between operations
...
The operations are design to have as many similarities and overlapping definitions as possible. For instance the getChecksums must work simmilar to Get. Paging of data and parameters must work in the same way. See dicussion on http://kb-dk.atlassian.net/wiki/display/BITMAG/Coordination+layer+design+discussion#Coordinationlayerdesigndiscussion-Overlapmedprotokolspecifikation.
Paging af requests
...
It must be possible to make paging of request parameters. Paging of parameters can for instance be the case for object ids in a random check of files. It is needed since we cannot assume that clients can make prior pagination. See dicussion on http://kb-dk.atlassian.net/wiki/display/BITMAG/Coordination+layer+design+discussion#Coordinationlayerdesigndiscussion-Pagingafrequests.
Software
Independence
In the design we need to ensure that we are as independent of the software chosen as possible. If special features are used, e.g. for optimisation, then the design must be flexible enough to skip use of the special features at a later stage.
...
- it is sufficient to identify a data transmission transaction by a token
- the token is sufficient information as basis for completion of a data transmission
Use of tokens
Tokens are used as designation of where the data can be put to or downloaded from.
...
Paging
Paging is in the first versions managed by a simple mechanism where a segment of a file is identified by parameters. Any Get command can contain an offset along with a length parameter, which defines the segment of the file. this is also sufficient to handle receival of divided files, and thus enabling rudimentary support of restart of an interrupted transmission.
...