Transfer file

THIS PAGE IS DEPRECATED: READ File transfer

Bagaimana cara menggunakannya?

Android

Saat Anda berbicara dengan seseorang di Android, Anda memiliki kemungkinan untuk mengirim gambar di perangkat Anda atau mengambil foto dengan tombol ini:

Catatan

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

Bagaimana cara kerjanya?

Bagaimana cara kerjanya

Pambuka

Jami adalah aplikasi terdistribusi dan harus bekerja tanpa koneksi internet. Jadi, transfer file juga! Pada dasarnya, kita menggunakan metode yang sama untuk melakukan transfer file dan panggilan, tetapi di TCP. Untuk merangkum bagaimana cara kerjanya, kita dapat membayangkan situasi di mana Alice (A) ingin mentransfer file ke 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.

Sekarang bahwa tautan TCP bidirectional di sini, langkah selanjutnya akan negosiasi TLS 1.3 (umumnya (TLS1.3)-(DHE-FFDHE8192)-(RSA-PSS-RSAE-SHA384)-(AES-256-GCM) ketika saya menulis baris ini) antara Alice dan Bob, kemudian Alice akan mulai mentransfer file.

Bagian pertama akan menjadi header kecil untuk menggambarkan isi file. Kemudian, setelah Bob menerima transfer, file penuh akan dikirim.

Proses

Mengirim file

Metode berikut digunakan:

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.

! TLSsocketEndpoint

Menerima file

Struktur yang sama digunakan untuk menerima file, tetapi metode berubah sedikit:

1. Kelas JamiAccount digunakan untuk menerima pesan dari DHT, karena hal pertama yang diterima akan menjadi permintaan DHT.

2. Kemudian, pesan ini diberikan ke DhtPeerConnector: onRequestMessage() melalui eventLoop.

3. DhtPeerConnector::Impl::answerToRequest akan mencoba untuk terhubung ke server TURN (jika tidak terhubung) dan menginisialisasi transportasi ICE. Metode ini akan membuka 2 koneksi kontrol ke server TURN (satu untuk mengizinkan peer IPv4, yang lain untuk peer IPv6, karena RFC 6156) jika belum terbuka dan memungkinkan alamat publik Peer untuk terhubung. Kemudian, jika SDP yang diterima tidak mengandung calon ICE, akan menggunakan TURN dan membuat jawaban SDP untuk menunggu peer. Jika SDP mengandung calon ICE, metode ini akan mencoba untuk bernegosiasi tautan (atau mundur pada TURN) dan kemudian menjawab SDP (dengan calon ICE atau tidak).

4. Setelah tautan siap, seperti pengirim, tautan TLS diprakarsai dan diberikan kepada PeerConnection diberikan kepada IncomingFileTransfer sebagai input. Header file akan datang dan klien sekarang dapat menerima atau membatalkan transfer.

Minta ulang transfer file sebelumnya

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.

Untuk melakukan ini, perangkat akan mengirim json dengan tipe mime: application/data-transfer-request+json berisi conversation (id percakapan), interaction (interaksi terkait), deviceId perangkat yang menerima file.

Pengirim sekarang memeriksa apakah perangkat itu adalah perangkat dari peer yang diumumkan dan bahwa perangkat itu adalah anggota percakapan, dan dapat mengirim file melalui transfer file klasik.

Penerima sekarang dapat menerima transfer masuk pertama, mengunduh file dan memverifikasi bahwa sha3sum benar.

Skema

! Diagram: diagram utama

SDP dikirim melalui 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).

Patch yang berhubungan dengan PJSIP.

3 patch akan dimasukkan ke dalam proyek PJSIP:

1. RFC 6062, digunakan untuk melakukan TURN melalui TCP (digabung ke atas arus: pjproject - fa6616c43c7e19797084f4e02a67d1fb6fd99473)

2. RFC 6544, digunakan untuk melakukan ICE di atas TCP

3. Perbaikan untuk pj_activesock

Perhatikan bahwa tumpukan untuk transfer file adalah:

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

Perangkat multi

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.

Pendekatan pertama

Pendekatan pertama adalah mengirim permintaan melalui DHT ke semua perangkat dan perangkat pertama yang menjawab mendapatkan file untuk ditransfer. Ini buruk untuk kontak Anda karena mereka tidak akan tahu perangkat mana yang akan menerima akan mendapatkan transfer.

Pendekatan saat ini

Sekarang, kita masih mengirim permintaan ke semua perangkat. Perbedaan adalah bahwa semua perangkat akan memiliki pemberitahuan untuk menerima file dan dapat menerima / menolak transfer. Bagian utama dari kode untuk itu adalah di 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.

Dalam data_transfer.cpp kita mendefinisikan kelas OptimisticMetaOutgoingInfo yang mewakili tampilan optimis untuk ditampilkan kepada klien. Ini optimis karena jika kontak menerima transfer pada satu perangkat dan menolak pada yang lain, kelas ini akan menunjukkan transfer file yang sedang berlangsung. Dan itu hanya akan menunjukkan kesalahan jika semua perangkat menolak transfer.

Kelas ini terkait dengan SubOutgoingFileTransfer yang mewakili keadaan transfer dengan satu perangkat. Klien akan memiliki kemampuan untuk menunjukkan sub transfer yang optimis nanti (lihat daftar TODO).

Menggunakan server TURN lain

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 turnserver -a -v -n -u pengguna:password -r "realm"

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

Catatan

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).

Daftar TODO

1. Use libtorrent?

2. Tampilkan status subtransfer untuk file yang keluar