webp2p

INTERNET DRAFT Jesús Leganés Combarro "piranna" Document: draft-piranna-webp2p-00 (independent) webp2p Abstract This draft describes a protocol by which two machines can discover and interconnect using WebRTC to create a P2P network, being able to use for handshaking a PubSub service or third peers on the network. Status of this Memo This Internet-Draft is work-in-progress. Copyright Notice Copyright (c) 2013 the persons identified as the document authors. All rights reserved. Table of Contents 1. Introduction....................................................1 2. Terminology.....................................................2 3. Messages........................................................2 3.1 Serialization and communication scheme.......................2 3.2 Presence.....................................................3 3.3 Handshaking..................................................4 3.3.1 Offer....................................................4 3.3.2 Answer...................................................5 4. References......................................................5 5. Authors' addresses..............................................5 1. Introduction This specification describes a protocol to create an interconnect several machines on a P2P network using WebRTC DataChannel objects. It could be also be used as a WebSockets subprotocol or over any other bi-directional transport layer like BoSH using a server that can connect the peers between them for example in a connections's pool, specially required during the initial handshake. It is based on JSON [JSON] messages. The actions the interface exposes are: * presence: notify our presence on a pool of connections so that other older peers can send to us request to create a direct connection. This message is not required when using other peers for the handshake. * offer: ask to a peer to create a direct connection * answer: response to a previous offer message The exact details of these three actions are described in this specification. piranna [Page 1] Internet-Draft webp2p March 2013 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [WORDS]. "SHOULD" and "SHOULD NOT" are appropriate when valid exceptions to a general requirement are known to exist or appear to exist, and it is infeasible or impractical to enumerate all of them. However, they should not be interpreted as permitting implementors to fail to implement the general requirement when such failure would result in interoperability failure. "UID" is an unique ID that identify the peer on all the network, both selected by the user (so it can be easily reacheable) or assigned automatically. In that last case, for annonimity it's recommended to use the UUID scheme [UUID], version 4 (random). "Handshake server" is a third party service external to the P2P network used to help on the initial bootstrapping of the peers. It can be used any transport layer that allow one-to-one communications and to send presence notifications (or one-to-many communications instead), desirelly in an anonimous way. Examples of this are PubNub servers, XMPP, PuSH protocol or private timelines on microblogging sites. 3. Messages 3.1. Serialization and communication scheme Communication is done using a simplified version of JSON-RPC, using arrays to store the command in string format on the first position, and the arguments of that command in their most natural format (boolean, integer, string, object...) on the other ones. The array is stringified using the JSON format previously to be send. Ending 'falsy' arguments (0, null, undefined, void...) are not added to the arguments list to earn bandwidth and should be filled ad-hoc by the receiver. Once the command is serialized, it would be like in the next example: ["command.name", true, "arg 2", 3.0, 4, [1,2,3,4,5], "6th argument"] On the receiver end, the JSON string would be parsed and an array with this items in the same order they were sended will be created. Communication is done in a totally asynchronous way, not waiting for an answer and processing all the messages in the order they are being received, no matter if a response was being waited from a previous request or not. piranna [Page 2] Internet-Draft webp2p March 2013 3.2. Presence Presence message is used to notify our presence when connecting to a handshake server so other (older) peers connected to it can send to us connection offers, so we can integrate on the P2P network. It's just the command 'presence' with the UID of the new peer as the only one argument, like: ["presence","550e8400-e29b-41d4-a716-446655440000"] After sending the presence message, the peer keeps waiting listening for the arrival of presence messages from new peers, choosing to send them a connection offer or not according to the number of newer peers it got connected thanks to this handshake server. When it got connected to a predefined number of newer peers (a "critic mass") it disconnect itself and start using exclusively the P2P network to discover new peers, allowing to new peers to use the handshake server and increasing network arity. The method to choose if the peer should connect to the newer peer or not is left to the developer, but the next three algorythms are proposed: * connect to all newer peers. This allow to quickly increase the number of connections with newer peers, but all of them would be in a reduced slice of time. * connect randomly: this allow a greater time arity of the network, but would spend a lot of time to get the critic mass and disconnect. * connect on increasing intervals: increase progresively the number of "leap" peers when connecting to them, both randomly or numerically. This would spend a lot of time to get the full critic mass, but also will assure that we got a big enought number of peers just after connecting to the handshake server. After disconnecting from the handshake server, it's left to the developer if it should connect to a new one (if available) or not. piranna [Page 3] Internet-Draft webp2p March 2013 3.3. Handshaking 3.3.1. Offer When a peer want to connect to another one, both on the initial handshake with a new peer after being notified of its presence or to make a transfer, it sends an 'offer' message. It has the destination UID as first argument, the offer SDP as second one and an array as third one having a list of the peers where the message have been routed, being empty on first instance. An example message would be: ["offer", "550e8400-e29b-41d4-a716-446655440000", <offer SDP string>, []] After checking that we don't really have a connection to that peer, in case the connection is for a new peer it is send directly over the handshake server connection where we got notified about it, otherwise it is broadcasted over all our current connections. When the offer message reaches a peer check if it's the one desired (the one on the destination field) and if not, append the UID of the peer where we receive it on the route field. Handshake server are considered regular peers for routing purposes, so they have a descriptor (usually the service name) as UID. Later the peer check in the destination field its one of its connections. If so, it sends the message directly to him but if not, it broadcast the message over all its current connections (except the one where it got the message or the ones already routed) as it was done with the original message flooding all the P2P network just to find a route to it, if it really exists. To prevent the message to being running infinitelly on the network, previously to being processed and dispatched it is check if our peer UID is on the route argument, showing us that this message have been previously routed by us and discarding it. When the offer message reaches the desired peer a new PeerConnection is created to hold the connection with the requested peer if we don't have it already, and apply to it the SDP from the message. piranna [Page 4] Internet-Draft webp2p March 2013 3.3.2. Answer After processing the offer message, a new 'answer' message is generated. This message has the origination (the UID of the peer that send the answer message) as the first parameter, the answer SDP and the offer route, so it can be runned backward looking the peer that sended the offer message. An example message would be: ["answer", "1a66b984-89d3-11e2-8bc3-4f265af2680c", <answer SDP string>, ["550e8400-e29b-41d4-a716-446655440000", "1b70093e-89d3-11e2-90c8-2f82ef7d7182"]] When a peer receive an answer message it check if it was sended back to us or the route array got empty and we don't know where to send it, so it's ignored. After that, we check if it was send to us (looking if the first UID on the route array if ours) so connection can be stablished with the SDP that's attached on the message, or we can re-send it back running over the route array. In that case, run over all the UIDs on the route array looking for possibly newly connected peers while the offer/answer dance was being done that would allow some shortcuts on the route sending back the answer message, and send to them it. In case no connected peer was found on the route (maybe they got disconnected), then send the message by broadcast so the message can look the path to the offering peer. When a connection is stablished between two PeerConnection objects, is suggested that both ends create new DataChannels that can be used for routing purposses to increase the network arity. This newly created DataChannels can be used for application specific usage too. 4. References [WORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [JSON] D. Crockford, "The application/json Media Type for JavaScript Object Notation (JSON)", RFC 4627, July 2006. [UUID] P. Leach, "A Universally Unique IDentifier (UUID) URN Namespace" RFC 4122, July 2005. 5. Authors' addresses Jesús Leganés Combarro "piranna" (independent) Email: piranna@gmail.com piranna [Page 5]