KOSH

Delivery Service

Translate
The cybersea consists of a set of entities held within a container, the sea itself. The power and potential of KOSH lies in the ability of the entities to interact with each other. Interaction involves the movement of messages, entities and content throughout the cybersea. The delivery service is the service that provides this functionality. Without it, entities would lead a lonely life, with no ability to improve or extend themselves, or to enrich the cybersea of which they are a part.

Delivery involves the transfer of one or more entities from one entity to one or more entities. Logically, a sending entity must first obtain the citizen ID of the receiving entity, and process all associated security directives (perhaps A is not allowed to talk to B). It must then build a parcel ( a special container entity that can hold other entities - very similar to a freezer (see immigration)).

The transmission of data can be discrete (packets) or continuous (streaming). For discrete transmission, one or more receiving entities must be specified. For publish and subscribe or multicast transmission, a broker entity would be used. Since delivery is a service and can be managed, its implementation allows for QoS. For continous delivery, a distinct information channel would be set up, allowing for a dedicated and more controllable provision of service.

Whilst cyberseas are logical entities and exist irrespective of the underlying hardware matrix, the delivery service itself distinguishes between local (within the same cybersea), near (a different cybersea but on the same machine), middle (a different machine on the same LAN), and far (separate lans, passing through multiple networks). This information is implementational in nature and is presented here only for completeness. An entity knows nothing about this distinction when it decides to make use of the delivery service.

By far the most common use of the delivery service is to pass messages between entities. This involves the creation and population of a message entity. However, the delivery service can also pass sets of entities from one entity to another, anything from a set of messages to a set of matter entities (e.g. data files).

The delivery service offers different levels of service and features. A partial list includes;
  • One way, no acknowledgement
  • One way, synchronous acknowledgement (wait for ack)
  • One way, asynchronous acknowledgement (don't wait for ack)
  • One way, tracked
  • One way, instructed
  • One way, continuous
  • Two way
The first 3 services refer to acknowledgement. This is provided by the delivery service itself and can refer either to the package being placed in the target entity's in box (the collection of communication ports), the target entity acknowledging receipt of the package, OR the entity beginning processing of the package. "Tracked" requests that the delivery service return a set of either stage or heartbeat acknowledgements, allowing the sender to keep an eye on the progress of the delivery. "Instructed" allows the sender to specify precisely the delivery actions. "Continuous" refers to streaming delivery. Two way informs the delivery service to hold an open channel between the sender and receiver, and comes with a set of supporting services. It is used when there will be two way delivery, for instance, asking for an entity to be created and receiving it.