Transfert de fichiers

THIS PAGE IS DEPRECATED: READ File transfer

Comment l’utiliser?

Android

Lorsque vous parlez à quelqu’un sur Android, vous avez la possibilité d’envoyer une photo sur votre appareil ou de prendre une photo avec ces boutons:

Je suis en train de faire une vidéo de mon blog.

Note

When you send a file, the other has to accept it. At this moment you will see “awaiting peer”:

Je suis en train de faire une vidéo de mon blog.

Comment ça marche?

Comment ça marche

Introduction

Jami est une application distribuée et doit fonctionner sans connectivité Internet. Donc, le transfert de fichiers aussi! fondamentalement, nous utilisons la même méthode pour effectuer le transfert de fichiers et les appels, mais en TCP. Pour résumer comment cela fonctionne, nous pouvons imaginer une situation où Alice (A) veut transférer un fichier à Bob (B).

First, Alice will request a connection to Bob. To do that, Jami is using ICE (RFC 6544), a protocol used to negotiate links between peers. Alice will send, into an encrypted packet via the DHT the IP address of its device. So, when Bob receives the IP addresses of Alice, they will be able to negotiate a transport where Bob will be able to send packets to Alice. The negotiation can be successful, but if it fails, a TURN server will be used (the one configured into the settings) to perform the transfer. If the negotiation succeeds, Bob will send its IP addresses to Alice to perform the negotiation in the other direction. Note that the link is still not secure, so Bob will send the IP addresses through the DHT network in an encrypted message. If the second negotiation fails, the TURN will be used as a fallback.

Maintenant que le lien TCP bidirectionnel est ici, la prochaine étape sera de négocier un TLS 1.3 (généralement un (TLS1.3)-DHE-FFDHE8192)-RSA-PSS-RSAE-SHA384)-AES-256-GCM) entre Alice et Bob, puis Alice commencera à transférer le fichier.

La première partie sera une petite en-tête pour décrire le contenu du fichier.

Processus

Envoyer un dossier

La méthode suivante est utilisée:

1. A client will call DataTransferFacade::sendFile(). DataTransferFacade is the class corresponding to the API exposed for the clients. It is used to manage a view of the file transfers (the corresponding classes are DataTransfer, IncomingFileTransfer, OutgoingFileTransfer and SubOutgoingFileTransfer). This method will ask the linked JamiAccount to request a connection.

2. The method DhtPeerConnector: requestConnection() is triggered and creates a connection between all connected devices of the peer (found on the DHT). DhtPeerConnector is used to manage the main event loop which manage connections. When a device is found, the event loop will create a ClientConnector (which manage the connection for one device) and launch the process() method.

3. This method is used to initialize the ICE transport and put a PeerConnectionMsg (which contains the SDP message, see below) on the DHT and waits for a response (DhtPeerConnector::Impl::onResponseMsg).

4. Then a response is received from the DHT, which contains public addresses of the peer device. We can now negotiate a TLS link (directly via ICE, or via TURN as a fallback). This TlsSocketEndpoint is given to the PeerConnection object as an output and the transfer can start.

5. When the TLS socket is ready, the callback DataTransferFacade::Impl::onConnectionRequestReply is called, and a OutgoingFileTransfer is linked to the PeerConnection as an input. This OutgoingFileTransfer contains a list of SubOutgoingFileTransfer (one per device) where each sub transfer is a transfer to one device. We do that to be able to furnish the most optimistic view of the transfer (if a contact as 3 devices, where the contact cancel the transfer on one device, but accepted the transfer on the two others, the most advanced transfer will be shown).

6. The SubOutgoingFileTransfer will first transfer the header of the file, wait the peer acceptance (A « GO\n » message on the socket) and then will send the file.

7. If a cancel is received from the peer or the client or if the file transfer finish, the connection will be closed via a CANCEL message on the DhtPeerConnector::eventLoop() and the resources will be released.

Réception d’un dossier

La même structure est utilisée pour recevoir des fichiers, mais la méthode change un peu:

1. La classe JamiAccount est utilisée pour recevoir des messages du DHT, car la première chose reçue sera la demande DHT.

2. Ensuite, ce message est transmis à DhtPeerConnector: onRequestMessage() via l’événementLoop.

3. Le DhtPeerConnector::Impl::answerToRequest tentera de se connecter au serveur TURN (si ce n’est pas connecté) et d’initialiser le transport ICE. Cette méthode ouvre 2 connexions de contrôle à un serveur TURN (une pour autoriser les pairs IPv4, une autre pour les pairs IPv6, en raison de RFC 6156) si elle n’est pas déjà ouverte et permet aux adresses publiques de pairs de se connecter.

4. Une fois que les liens sont prêts, comme l’expéditeur, un lien TLS est négocié et donné à la PeerConnection donné à la IncomingFileTransfer comme entrée.

Re- demande pour un transfert de fichier précédent

As specified in Other mime types, the data-transfer interactions are now synced and stored into conversations. So, a device can easily detects if a file was downloaded or not. If not, it can asks all members in the conversation to transmits the file again.

Pour ce faire, l’appareil enverra un json avec le type mime: application/data-transfer-request+json contenant conversation (id de la conversation), interaction (interaction liée), deviceId l’appareil recevant le fichier.

L’expéditeur vérifie maintenant si l’appareil est un appareil de l’annonceur et que l’appareil est un membre de la conversation, et peut envoyer le fichier via un transfert de fichier classique.

Le récepteur peut maintenant accepter le premier transfert entrant, télécharger le fichier et vérifier que la somme sha3 est correcte.

Schéma

[Diagramme: schéma principal]

SDP envoyé par le DHT

0d04b932
7c33834e7cf944bf0e367b47
H6e6ca682 1 TCP 2130706431 2607:fad8:4:6:9eb6:d0ff:dead:c0de 50693 typ host tcptype passive
H6e6ca682 1 TCP 2130706431 2607:fad8:4:6:9eb6:d0ff:dead:c0de 9 typ host tcptype active
H42c1b577 1 TCP 2130706431 fe80::9eb6:d0ff:fee7:1412 50693 typ host tcptype passive
H42c1b577 1 TCP 2130706431 fe80::9eb6:d0ff:fee7:1412 9 typ host tcptype active
Hc0a8007e 1 TCP 2130706431 192.168.0.123 42751 typ host tcptype passive
Hc0a8007e 1 TCP 2130706431 192.168.0.123 9 typ host tcptype active
Sc0a8007e 1 TCP 1694498815 X.X.X.X 42751 typ srflx tcptype passive
Z.Z.Z.Z:YYYY
A.A.A.A:YYYY

Where 0d04b932 is the ufrag and 7c33834e7cf944bf0e367b47 the password of the ICE session. 2130706431 and 1694498815 are the priority of the candidates. 192.168.0.126 42751 typ host tcptype passive is a passive host candidate and 1694498815 X.X.X.X 42751 typ srflx tcptype passive a passive host reflecting the public IP address (mapped via UPnP for example).

Les correctifs liés au PJSIP.

3 correctifs seront inclus dans le projet PJSIP:

1. RFC 6062, utilisé pour effectuer le TURN sur TCP (fusé en amont: pjproject - fa6616c43c7e19797084f4e02a67d1fb6fd99473)

2. RFC 6544, utilisé pour effectuer des ICE sur TCP

3. Une correction pour pj_activesock

Notez que la pile pour le transfert de fichiers est:

+-----------+----------------+-----------------------+
+    STUN   +    TLS data    +          TLS data     +
+-----------+----------------+-----------------------+
+     RFC  4571 (RTP)        +  RFC  6062 (TURN TCP) +
+----------------------------+-----------------------+
+                           TCP                      +
+----------------------------------------------------+

Des appareils multiples

A user can link its account to several devices. So, we need to implement the transfer when a user send a file to a contact who have multiple devices linked to this account.

Première approche

La première approche consistait à envoyer une demande via le DHT à tous les appareils et les premiers appareils qui répondent obtiennent le fichier à transférer.

Approche actuelle

Maintenant, nous envoyons toujours une demande à tous les appareils. La différence est que tous les appareils auront la notification de recevoir un fichier et peuvent accepter/rejeter le transfert. La plupart du code pour cela est dans data_transfer.cpp.

Now (since https://review.jami.net/c/jami-daemon/+/9327), when a user send a file, it will request a PeerConnection with all peer devices. And for all connections, we attach a new input stream to have the ability to accept/refuse/cancel each transfer separately.

Dans data_transfer.cpp nous définissons la classe OptimisticMetaOutgoingInfo qui représente la vue optimiste à montrer au client. C’est optimiste parce que si un contact accepte un transfert sur un appareil et refuse sur d’autres, cette classe affichera le transfert de fichier en cours. Et il ne montrera une erreur que si tous les appareils refusent le transfert.

Cette classe est liée à SubOutgoingFileTransfer qui représentent l’état d’un transfert avec un seul appareil. Les clients auront la possibilité d’afficher un transfert sous-optimisé plus tard (voir liste TODO).

Utilisation d” un autre serveur TURN

Actually the default TURN server is turn.jami.net. But you can host your own TURN server. For example by running a coTURN server.

`sudo tourne-serveur -a -v -n -u utilisateur: mot de passe -r « realm »

Then, you can configure the TURN server in the advanced settings of the app.

Note

This needs some technical knowledge. Moreover, the TURN server should see the same IP address of your node as the destination node, or the peer connection will fail (because the authorization will be incorrect).

Liste de TODO

1. Use libtorrent?

2. Afficher l’état des sous-transférences pour les fichiers sortants