- From: Wenyu DONG via GitHub <sysbot+gh@w3.org>
- Date: Fri, 23 Dec 2016 10:24:24 +0000
- To: public-webrtc@w3.org
warnard has just created a new issue for
https://github.com/w3c/webrtc-pc:
== 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
files.
Secondly, the sender should calculate the finger-print of the file,
and transfer it to the receiver, for example via session negotiation
procedure.
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
procedure.
### 3.2 Sender’s Action
Before transferring, the sender should submit:
_a=file-selector: name:…….. type:…. size:…. hash:<fingerprint
algorithm>: <fingerprint value>_
e.g.
_a=file-selector:name:"1.rar" type:application/octet-stream size:10
hash: SHA-1:
72:24:5F:E8:65:3D:DA:F3:71:36:2F:86:D4:71:91:3E:E4:A2:CE:2E_
### 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
file
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