Internet DRAFT - draft-nihao-discoveryprotocol
draft-nihao-discoveryprotocol
Nihao Protocol Individual Group
Internet-Draft
Expires: March 1, 2012
The Nihao Discovery Protocol
draft-nihao-discoveryprotocol-00
Abstract
The Nihao Protocol is an open source protocol that uses the
Extensible Markup Language (XML), and simple UDP datagram
exchange. It's designed for quick (and unencrypted by default)
discovery and communication with other devices on a local
network. This document will show you how the Nihao protocol
works internally, allowing you to write wrapper libraries on
the protocol and implement it in your own applications.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF). Note
that other groups may also distribute working documents as
Internet-Drafts. The list of current Internet-Drafts is at
http://datatracker.ietf.org/drafts/current.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in
progress."
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (http://trustee.ietf.org/
license-info) in effect on the date of publication of this
document. Please review these documents carefully, as they
describe your rights and restrictions with respect to this
document.
Headers
The Nihao Protocol requires that you include a simple header
in all sent packets that comes before your XML command. The
header tells receiving devices that you're using the Nihao
Protocol, and it tells them simple information about you and
your device. A header is made up of 4 components, plus a line
break at the end (\r\n) that specifies that start of XML data.
A header looks like the following:
NIHAO:name,via,client\r\n
As you can see the header starts out with the text NIHAO and
then a colon which tells the receiving entity right away that
you're using the Nihao protocol. After that comes your header
components separated by commas; the contents contains your
name (SHOULD be the host name of your device or the user's
name), your via (MUST be either mobile or desktop), and your
client (SHOULD be the name of the application).
Discovery
The main function of the Nihao Protocol is finding other
devices that are setup to respond to discovery requests. A
discovery request is a command that's broadcasted over the
network (sent to everyone that's connected to the network),
any device who responds to the message is telling the requesting
device that they're there; if a device chooses not to respond,
they become invisible to the requesting entity. To send out a
discovery request, you broadcast (send packet to the IP address
255.255.255.255) the following data after your header:
<discover xmlns='com.as.nihao' type='get' />
Any receiving devices SHOULD respond with the following (if
they don't they will be invisible) by sending directly to the
requesting IP (as opposed to a broadcast):
<discover xmlns='com.as.nihao' type='result' />
The type GET indicates that you're requesting discovery, the
type RESULT indicates that you're responding to a discovery
request. Clients CANNOT randomly generate responses with the
type RESULT, as it could cause duplicate entries on a requesting
device list (unless they have measures against it).
When a client gets a discovery request (with type 'get'), it
should check it's list of discovered devices to see if it's
there, if not, the device probably came online after a previous
discovery request and SHOULD be added now.
Information Exchange
Devices can request information from other devices, this
information could have an infinite amount of contents
possibilities, such as hardware information about a device
(make, model, etc.) or profile information about a human
(e.g., for a local social network). To send out an info request,
you send the following data directly to a device (as opposed
to broadcasting):
<info xmlns='com.as.nihao' type='get' />
The receiving device SHOULD respond with their information using
the following:
<info xmlns='com.as.nihao' type='result'>
<key1>key1-value</key1>
<key2>key2-value</key2>
</info>
You can name the child nodes whatever you want, and specify any
type of information in them, such as a child node with the name
"phone" and your phone number as its inner text. Notice the type
values GET and RESULT just like in the Discovery section.
Applications can choose to encrypt this with their own encryption
methods if they don't want other people to intercept their info
(e.g., using MITM attacks or radio tapping). Devices will only
be able to receive encrypted info if they're using the same
application, or happen to be using the same encryption method.
Chat Message Exchange
Devices can send chat messages to each other, containing plain
text that's readable by humans, just like instant messaging on
Google Talk or Facebook. Applications can choose to encrypt this
with their own encryption methods if they don't want other people
to intercept messages (e.g., using MITM attacks or radio tapping).
Devices will only be able to receive encrypted messages if they're
using the same app, or happen to be using the same encryption
method. To send a message, you just send the following directly
to your chat recipient:
<chat xmlns='com.as.nihao'>message contents</chat>
Applications SHOULD NOT broadcast chat messages; if there was 40
other devices on your network chatting, and the applications being
used by the devices all decided to broadcast chat messages, you
would be flooded with messages almost every second. Applications
should still have a way of filtering this in case others still
decide to do so, such as only accepting chat messages sent with a
header that has the same "client" type.
Further Interaction
If an application needs further interaction, such as transferring
large amounts of data (like files), it should use TCP (Transmission
Control Protocol). Unlike UDP, TCP is connection based and is more
reliable for exchanging large amounts of data with any data loss.
Going Offline
When a device will no longer be responding to requests and receiving
chat messages, they should broadcast the offline message. To go
offline, you broadcast (send the packet to the IP address
255.255.255.255) the following command:
<offline xmlns='com.as.nihao' />
This will tell any devices that have you in their "discovered list"
to remove you allowing applications to keep a clean and organized
list of online devices.
Aidan Follestad
Expires: March 1, 2012
