The Object Network is naturally symmetric and peer-to-peer. The internet is currently asymmetric and client-server. It was originally intended to be symmetric, but we ran out of IP addresses, so had to invent a hack to fix that (NAT). The newer internet standard, IPv6, is the correct fix for the age of the Internet of Things, giving everything we can name its own IP address and, at least in theory, allowing our watch to talk directly to our mother's front room light, peer-to-peer.
So the Object Network will be IPv6-native, and peer-to-peer by design, only going asymmetric and client-server when there are barriers like the mobile network that prevent such direct communication.
Another networking technology choice is connection-oriented versus connectionless (TCP versus UDP). Connections are always from a client to a server, and thus inherently asymmetric. Connectionless interactions are symmetric, made of independent one-off messages between peers. These are a better match for the way the Object Network works: spontaneous observations and notifications of object state in any direction.
So again, the Object Network will be connectionless - using UDP - by design, only using TCP when forced to by network asymmetry.
The Object Network Protocol has much in common with the more recent research around Information-Centric Networking and Content-Centric Networking. The protocol is based around two types of message: observation and notification, which can be handled by intermediary peers that return cached content.
ONP is an instance of "Functional Observer REST" or FOREST.
Here's the basic interaction in ONP - requesting the state of another object.
Say uid-1 wanted to observe uid-2. First, host-1 sends an observe message on its behalf to host-2 requesting uid-2. This results in host-2 returning the state of uid-2, assuming host-1 has permission to see it, then successive updates to it.
At some point the observation will expire, at the discretion of host-2, and needs refreshing. So host-1 sends another observe message, and can tell host-2 which version it's on to prevent at least one redundant transfer per refresh.
There are no acknowledgements in the protocol, and no explicit unobserve - ONP is a best-effort, unreliable protocol that relies on interest being re-asserted or observations refreshed. The object layer above decides for itself how important an exchange is.
An object can spontaneously push itself to another object that it thinks may be interested in it. If that turns out to be the case, and the target wants to keep updated, it can follow this push with a normal observe message:
A host can try getting something from an intermediary, proxy or peer - host-3 here:
Here, uid-2 hasn't been needed in or from host-3, so has fallen out of date. But host-1 still gets what's available, and meanwhile, host-3 pings host-2 for an up-to-date copy, which it then forwards to host-1, along with any subsequent updates.
Each message can be carried by a UDP packet if small enough, or multiple packets with appropriate chunk indexing. For the IoT, messages may be carried by radio packets.
All objects can have a UID formed as an IPv6 address that is routed to their host. But the UID identifies the object, not its particular location, so it may be fetched from a local or intermediary cache, or even from a different source host or peer on the network to that implied by its IPv6 routing target.
Contact me and/or subscribe to my blog and/or follow me on Twitter.