[webrtc-pc] Enabling Fingerprint-based Instant Data Transferring in WebRTC

warnard has just created a new issue for 

== Enabling Fingerprint-based Instant Data Transferring in WebRTC ==
# Enabling Fingerprint-based Instant Data Transferring in WebRTC

### Author: DONG Wenyu, China Mobile dongwenyuyj@chinamobile.com

## 1. Introduction
When WebRTC is widely used in future, file transferring based on 
peer-to-peer Data will also be popular and used quite frequently. Then
 there comes a common situation that the sender is going to transfer a
 popular file which might already existe in the receiver’s devices, 
since the receiver may already have got this popularly spread file 
from someone else. In this situation, an optimized policy is that the 
sender need not transfer this file. Instead, it is enough to deliver 
the sender’s intention to the receiver.

## 2. Technical Solution
The solution lies in finger-print algorithm. To be more specific,
Firstly, every WebRTC node could cache a certain number of popular 
Secondly, the sender should calculate the finger-print of the file, 
and transfer it to the receiver, for example via session negotiation 
Thirdly, the receiver tries to search an identical file in its local 
cache according to the fingerprint, and inform the sender whether 
searching result.
Finally, the sender decide to send the file ‘physically’ in case the 
receiver does not have it.

## 3. Specification
### 3.1         Extension to RTCDataChannel
The RTCDataChannel should be added two more attributes indicating 
whether this WebRTC node supports fingerprint in either direction(s).
_interface RTCDataChannel : EventTarget {
readonly attribute boolean             sendFingerprint;
readonly attribute boolean              sendFingerprint;
These two attributes should be set during the SDP negotiating 

### 3.2         Sender’s Action
Before transferring, the sender should submit:
_a=file-selector: name:…….. type:…. size:…. hash:<fingerprint 
algorithm>: <fingerprint value>_
_a=file-selector:name:"1.rar" type:application/octet-stream size:10 
hash: SHA-1: 

### 3.3         Receiver’s Reply
If the receiver find a matched file in its cache, it should reply the 
following attributes, e.g.
_a=file-range: filesize-filesize     //need the last 0 byte of the 
a=setup:inactive     //no need to transfer the file ‘physically’_

Please view or discuss this issue at 
https://github.com/w3c/webrtc-pc/issues/981 using your GitHub account

Received on Friday, 23 December 2016 10:24:26 UTC