Update File transfer

This commit is contained in:
Sébastien Blin 2019-04-19 14:32:23 -04:00
parent c6dca80ff4
commit e36eac1039
1 changed files with 17 additions and 29 deletions

View File

@ -63,7 +63,23 @@ The first part will be a small header to describe the content of the file. Then,
##### Receiving a file
**TODO**
The following method is used:
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.
**TODO schema**
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.
##### Schema
@ -108,34 +124,6 @@ Note that the stack for the file transfer is:
```
#### Sending files
The following method is used:
1\. A client will call **DataTransferFacade::sendFile()**
2\. The method **DhtPeerConnector: requestConnection()** is triggered and
creates a connection between all connected devices of the peer. This
will create a **ClientConnector** and launch the **process()** method.
3\. This method put a *PeerConnectionMsg* on the DHT and waits for a
response (**DhtPeerConnector::Impl::onResponseMsg**). The reponse will
contains informations to connect to the peer.
4\. Then a response is received from the DHT, which contains public
address of the contact. A **TcpSocketEndpoint** is created and wrapped
in a **TlsSocketEndpoint** wrapped in a **PeerConnection** object (and
launch **PeerConnection::PeerConnectionImpl::eventLoop()**)
5\. This connection is given to
**DataTransferFacade::Impl::onConnectionRequestReply** and attached to a
**OutgoingFileTransfer**
6\. **PeerConnection::PeerConnectionImpl::eventLoop()** as soon as the
output is connected will send headers (from **SubOutgoingFileTransfer**)
to the peer. And will wait for the "GO" message (or "NGO"). Then if
headers are sent and the file accepted, it will send the rest of the
file until the connection is closed or the file is finished.
#### Receiving files