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: 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): 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): The receiving device SHOULD respond with their information using the following: key1-value key2-value 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: message contents 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: 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