- 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