This page defines the WOSH interfaces, protocols, assumptions/rules in one word: Specifications.

Table of Contents:

This page is out-of-date and still transitional from WOSH 0.6.030 [ byron ] to WOSH 0.8.499 [ icarus ].



Platforms and Requirements

WOSH core and framework components must be as scalable as possible. They are intended to run on workstations, servers, but also on ATX and embedded devices (as a smart phone).

Two programming languages are suitable for that purpose: C++ and Java. WOSH is coded in ANSI C++. Requires STL.

As many developers, I have written ASM code even in C++ software. When I develop in an interpreted language, I really have some reasons.

WOSH Framework (especially the Core) shall have fewest requirements as possible.

Actually compiles on any common PC, ATX platform, WindowsCE/Mobile 6.0 or later.

A custom (kiosk front-end) software is under planning for ATX devices (+touchscreen).

Further, a custom micro-kernel (probably based on TinyOS) will be implemented for Wireless Sensor Networks, a WSN server service will act as gateway between the two distributed networks.

as release 0.8.499, WOSH is still partially based on QT4, so it is required.


DRY ( Don't repeat yourself )


WOSH is definitely a flexible system, as single host/process and as distributed software both. Each process/host (instance) may be seen as a MicroKernel offering a set of low level services to its bundles (which are applications by WOSH's point of view).

Some example of flexibility are:


Especially when talking about reliability, availability and "fault tolerance" within WOSH system, we must refer to a specific scope, there are two main contexts:

Let's see two opposite, but common examples:

Actually WOSH Kernel and Core-Modules are NOT based on a globally shared memory, neither implement synchronization strategies. This is the next HUGE step of core-design-implementation.

Performance is a single WOSH is very high. The price to pay for developers is the assumption messages are delivered successfully, its is not true within an instance and within a network both. This is not a design choice and depends mostly on wosh::Bus and wosh::NetworkChannel implementations. Adding more I/O queues and (N)ACKs will bring the system to a Virtual Synchrony model.

More reliable communication channels is under planning.

WOSH is a scalable system, running as the core of a graphical front-end or as server hosting many bundles. The main goal is to provide a simple middleware on which application (such as bundles) lives.

A good example of scalability is an embedded device like my Windows Mobile smart-phone, the wosh::bundles::WindowsMobileBundle bundle implements various TAPI services (telephony: SMS, calls) masquerading to high-level methods. Thanks to WOSH portability there is no need to implement a custom client-server protocol/software to expose such services to the whole network, in fact the WOSH layer will make it available as any other service on other hosts.


WOSH system(s) is actually based on the controversial assumption that the network (LAN,WLAN) and the PC(s) are secure. This comes with current implementation of the communication channels, such wosh::network::ChannelTcpServer and wosh::network::ChannelTcpSocket, which are NOT providing authorization/security features. However, it is acceptable (for now) to trust the TCP connections within local LAN/WLAN (and the connected hosts).

WOSH system has vulnerabilities as any other networked/distributed application, main critical sections are:

Once the previous points are assumed, there are also some good news: WOSH is a multi-user (multi-group) system supporting access control, very similar to POSIX standard.

The most common operation performed by a security subsystem is proving a user’s identity. In a common example, a user asserts their identity with their login user-name and password (the step of authentication), and then asserts (by authorization)

One of the less-considered, but equally important matters that a security subsystem should take care of is peer authentication. It is readily accepted that the user must prove their identity to a server, but with a few exceptions (mostly involving ‘secure’ websites), users do not expect a server to prove its identity to them. Proof of server identity is a very important issue, as soon as any of the information given by that server needs to be trusted. Often called ‘mutual authentication’, a solution to this problem ensures that the server is ‘trusted’ not to provide malicious data.

Once the identities of a server and client has been established, there must be some way to ensure that only that server or client can continue to communicate with the other. Otherwise, it may be possible for an impostor to take over a connection and impersonate one party to the other. (connection hijacking) The practice of data integrity, also known as ‘signing’, typically requires a cryptographic calculation designed such that both sides can prove these facts: This signature could only have be performed by the other party, and could only have been constructed over the data received. If the output of that calculation does not match the value supplied by the other party, the message must be considered compromised.

The components of distributed systems, whether object-oriented or not, have to communicate via a network. If hosts are directly-connected to public networks, such as the Internet, any network traffic to or from the host is publicly accessible. Individuals wishing to launch security attacks can obtain connections to a public network, because there are no restrictions on connecting machines to a public network. This means that an attacker can use a public network to send messages to distributed system components in an attempt to compromise the system security. An obvious approach to avoiding security problems is to physically separate the network from the public network.


There are different forms of security threat. [Colouris et al., 1994] classify them into four different categories and we followthis classification.


Centralized applications that are written using object-oriented programming languages often deal with security at a session level. They request users to identify themselves during an authentication procedure at session start and then they trust that the user will not make the session available to unauthorized users. Distributed objects may communicate over insecure networks, where attackers can openly access network traffic.

Hence, it is not sufficient to authenticate at a session level but individual requests might have to be authenticated. Moreover, server objects have to be able to decide whether a user or client that has requested execution of an operation is authorized to execute that request.

File System

WOSH provides some high-level functionalities for locating and manipulating (real) files, but do NOT come with an internal (distributed) File System. The underlying (Network) Operating System must provide it, when required.

When you are running a single instance of WOSH (so on a standalone host) you don't need any custom setup (such as aliasing, mouting).

WOSH defines a 'custom' file path format, that is the POSIX standard (/home/alex/myfile.cpp) and provides marshalling to the local file-system (such as on Microsoft Windows). Moreover WOSH internally supports aliasing with recursive resolution: set an alias as $MUSIC = "/archive/music" we can refer to a file as "$MUSIC/mySong.mp3", it will be translated (only when required, like real I/O access) to the correct local path on that system.

Assuming you have a networked file system (in other words you are sharing a disk on more hosts), each host can mount the disk to a specific (custom) local path and masquerade the access (in fact you access as local disk).

So, while on the server we will refer to "/archive/music/mySong.mp3", on a connected Windows workstation the file path is "Y:\music\mySong.mp3".

The major point of WOSH FileSystem Aliasing is "Naming Transparency", you may define different aliases on each host, making the (WOSH) file-path universal. In the example, the Windows WOSH host has defined alias $MUSIC as "Y:\music\".

"Location transparency" (the path name gives no hint as where the file is located) and "location independence" (files can be moved without their names changing) is under planning (but partially archived).


WOSH Framework claims to be a network distributed system and to provide an high layer of abstraction, making the network and configuration transparent to the user and almost transparent to the (Bundle) developer.

We can split the topic in three context:

The first point (Discovery) is implemented as a standard service (Bundle): wosh::bundles::DiscoveryUdpBundle. Discovery I/O is based on UDP protocol using the wosh::network::SocketUdp interface (an implementation of that). Basically, the service broadcasts a well-formatted Discovery packet over the network (to one or more addresses) and listens for incoming datagrams (from other hosts).

The outgoing packets' fields are loaded from wosh::NetworkManager core-service, as the incoming packets are converted to standard type wosh::WoshHost and forwarded to the Network Manager which keeps the Hosts list updated and evaluate further actions.

All communication in WOSH (and generally in distributed systems) is based on message passing (there is no shared memory).

Low-level communication is provided by ISO OSI layers (such as TCP) which are offered by the underlying (Network) Operative system.

WOSH framework offers an overlay network (transparent to the services).

Serialization is provided by wosh::Persistence module and marshalling is implemented by the communication channels.

By WOSH's point of view, channels are connection-oriented, even when the protocol is connectionless (such as UDP). Thus, message passing may be seen as connectionless (like UDP datagrams).

Each WOSH Kernel hosts (singleton) wosh::NetworkManager which hosts many different network channels and follow the client-server model (bi-directional).

Network Manager implements also the name service, mapping addresses (destination kernel name) to communication channel(s) (and even selecting one when more channels are available).

Each implementation of wosh::NetworkChannel may have different features, which usually depends on underlying layers (example: UDP vs. TCP), it's up to the system administrator to install and configure the network, but theoretically services shouldn't notice any difference. Because of that, we expect channels' I/O to be reliable (bad assumption).

WOSH hosts are (usually) "closed groups" (outsiders cannot send messages). Within a single host, services are "open groups", even if usually all services are subscribed to the Bus.

WOSH hosts may be organized as "peer or hierarchical groups" depending on the network and configuration. Busses are organized as "hierarchical groups" having wosh::BusManager as coordinator.

Network Manager supports broadcast and unicast addressing, with some forwarding functionalities.

unicast-forwarding and broadcast messages actually may produce duplicate queries, global-routing strategies need to be reviewed integrating the neighbours information and dynamic routing.
at-most-once message delivery: fix here when implemented: Networkmanager timestamp evaluation if TS(message) < TS(last-message) then DISCARD

Busses deliver messages as broadcast to all registered brokers. It's up to the service to discard or process the message. A lower, common layer (such as the one implemented by wosh::BundleGeneric) is provided for selection and RMI (remote method invocation). This pattern allows "predicate addressing", we may send a message to any service which validates some properties (such as their current state).

Atomicity is actually not provided at any level, especially in case of failures, but assuming non-faulty services (by the message-dispatcher point of view) Busses handle "atomic broadcast" property.

Message ordering is still up to the custom implementation of the Bus/Channel, we generally assume a FIFO (first in fist out) model.


Synchronization in distributed system is an huge task. Following properties should be assumed for WOSH Core and any service:

Shared Memory

Future (DRAFT) Specifications (not actually used/implemented):
See also:
Refer to WOSH.DSM.Spec.pdf

Users' Point of view

Rules and assumption of the WOSH system. This applies mostly in a distributed environment (more instances of WOSH-based software on a PC or more servers connected through a 'reliable' network).

Future Specifications (draft)

Future (DRAFT) Specifications (not actually used/implemented):

Generated on Sat Feb 26 2011 11:28:29 for WOSH system 0.8.888 [phoenix] by Alessandro Polo, using DoxyGen 1.7.2 hosted by WOSH Framework