- updated ft/, p3msgservice and p3chatservice accordingly
- added a new class for Sha1Sum in t_GeneridIdType<>, and an additional template argument to make ids of identical size
incompatible.
git-svn-id: http://svn.code.sf.net/p/retroshare/code/trunk@7082 b45a01b8-16f6-495d-af2f-9b41ad6348cc
- set desiredRate of peers to 10MB/s instead of 1MB/s
- maximum number of active chunks per peer is now 20 (that was a serious limiting factor)
- ticks that bring no data are not accounted for in the speed estimate anymore. The data is averaged over all ticks since the previous
non zero data chunk -> this brings much more stability to sources and removes lots of oscillation.
The maximum theoretical speed per source peer is therefore 13MB/s (in "Average" DL mode), whereas previously it was 1.3MB/s
git-svn-id: http://svn.code.sf.net/p/retroshare/code/trunk@6897 b45a01b8-16f6-495d-af2f-9b41ad6348cc
a transfer not finish if the original surce for a crc is not here anymore.
If you have a unfinished transfer do a force-check after restart to get back chunks that
where still on verificaiton stage.
git-svn-id: http://svn.code.sf.net/p/retroshare/code/trunk@5315 b45a01b8-16f6-495d-af2f-9b41ad6348cc
- tunnels can borrow data chunks from only slower tunnels, to prevent blocking fast tunnels
- tunnels can handle up to 50 data chunks at once instead of 5
Multi-source transfers are generaly faster and more stable.
git-svn-id: http://svn.code.sf.net/p/retroshare/code/trunk@5156 b45a01b8-16f6-495d-af2f-9b41ad6348cc
Validated chunks are shared to other peers. Force check is now very simple since it just turns all chunks into "needs checking" mode
and sums are asked to sources. Sources maintain a temporary cache of chunks. Since sums are requested sparsely, this should not
affect the sources in terms of performance. We can still imagine precomputing and saving sha1 of chunks while hashing them.
For backward compatibility reasons, the following has been setup *temporarily* in this version:
- unvalidated chunks are still considered as already obtained, and are shared and saved
- force check has been disabled
- final file check is maintained
- in case of file fail, the old checking mode will be used.
All changes for next version are kept in the define 'USE_NEW_CHUNK_CHECKING_CODE' that will be made the default in a few weeks.
At start, I expect most chunk to stya yellow during download, until most sources are able to provide chunk hashs.
git-svn-id: http://svn.code.sf.net/p/retroshare/code/trunk@5019 b45a01b8-16f6-495d-af2f-9b41ad6348cc
- corrected 2 potential flaws of swarming causing request of unavailable data (This should normally be taken care of on the server side!)
- improved swarming test code with fault simulation
- only ask CRC32 maps to peers that have a complete file.
git-svn-id: http://svn.code.sf.net/p/retroshare/code/trunk@4947 b45a01b8-16f6-495d-af2f-9b41ad6348cc
Changed the parameter of the constructor of ftFileCreator and ftFileProvider and some methods of ftTransferModule from "std::string" to "const std::string&"
git-svn-id: http://svn.code.sf.net/p/retroshare/code/trunk@4045 b45a01b8-16f6-495d-af2f-9b41ad6348cc
- by the right-click+Force Check on files.
- when a global hash on a downloaded file does not match the announced hash.
When a CRC map check is ordered, the CRC map is requested to one of the sources for the current file download.
When received, all downloaded chunks are checked w.r.t the reference CRC and marked as not done if the CRCs do not match.
The exchange of CRC32 map and requests has been tested, as well as CRC map checking during download (force check).
To be implemented soon:
- caching of CRC32 maps (although these are fast to compute)
- CRC32 map packets for normal downloads. For now these work only for turtle tunnels.
- handling of errors if the CRC never comes. For now, the download will stay stuck in "Checking..." mode.
So, don't play too much with the force check feature for now...
git-svn-id: http://svn.code.sf.net/p/retroshare/code/trunk@3310 b45a01b8-16f6-495d-af2f-9b41ad6348cc
.
- corrected a bug that caused file copy error: a closeFile() was missing when the file is complete. Because of delays in fwrite, the file would not be always co
mplete, nor exist at all for small files (e.g. cache files), which in the later case caused the copy error.
Warning: needs a make clean in libretroshare to recompile.
git-svn-id: http://svn.code.sf.net/p/retroshare/code/trunk@3261 b45a01b8-16f6-495d-af2f-9b41ad6348cc
- added failure tests for fwrite. Some where missing.
- added a test against the IP 1.0.0.0, which pops up on MacOS (when the peer is not connected to the internet?)
- put some additional debug messages.
git-svn-id: http://svn.code.sf.net/p/retroshare/code/trunk@3018 b45a01b8-16f6-495d-af2f-9b41ad6348cc
- suppressed old DwlQueue class
- turned mDownloads into a list of pointers to allow easy cross-info update between queue and std::map of downloads
- added queue functionality for moving files top/bottom/up/down
- added the necessary functions in rsFiles
Put back display of exact sizes in FileTransferInfoWidget
Suppressed some warnings.
**Warning**: this commit requires a make clean.
git-svn-id: http://svn.code.sf.net/p/retroshare/code/trunk@2493 b45a01b8-16f6-495d-af2f-9b41ad6348cc
- added file priority strategy based on which files are requested first. This provides:
- equal file speed for files with equal (source,priority)
- effective priority speed for file of same source but different priority
- removed state variable load/save from turtle, as it's not needed anymore (FileRequest re-opens tunnels as needed)
- manage availability per peer instead of per file type: direct peer ids always assume file availability, while turtle tunnels don't
I still need to make the download queue work, and code this gui for it.
git-svn-id: http://svn.code.sf.net/p/retroshare/code/trunk@2133 b45a01b8-16f6-495d-af2f-9b41ad6348cc
