Project

General

Profile

Actions
History

Home » Protocols »

Protocol core-core Version 3 » History » Revision 47

« Previous | Revision 47/73 (diff) | Next »
Greg Burri, 07/13/2009 08:26 AM

Protocol core-core

This page describes the protocol used by Aybabtu for network communication between cores.

See source:protos/network_protocol.proto for message details.

Downloading threads

There is NbDownloadThread threads. Each thread will choose a free chunk and download it. A peer cannot have more than one connection per other peer. A peer which a download is active is set as not free.

F : the list of all unfinished download
C : A list of chunk candidates (empty at start)

- Take the first file in F -> f.
Loop :
   If the hash chunks of f are unknown :
      If there is already a peer asking for hashes :
         - Take the next file in F -> f.
         - continue
      Else
         - Ask the hashes to the source (see the message 'GetHashes').
   For each chunk not downloaded and not being downloaded of f -> c :
      If c has a free peer :
         - Add c to C
   If C isn't empty :
      - Take the best chunk in C based on peer.downloadRate.
        If there is more than one best chunk then choose one randomly.
      - Grab the lock for the peer
      - Request the download (see the message 'GetChunk')
      - Take the first file in F -> f.
   Else :
      - Take the next file in F -> f.

Updating peer to hash association thread

This thread will periodically grab the NumberOfChunkToUpdate first chunks and request to all other peers what chunk they have.

If there is no chunk available the message will be send without hashes. This message is also used to know the peer on the network.

F : the list of all unfinished download
C : list of latest chunk hashes sent

Loop :
   Time.now -> t
   Empty C
   n : number of chunk = 0
   While take the next file in F -> f
      If C.count >= 'NumberOfChunkToUpdate' :
         - Break
      If we know the hashes for f :
         For all chunks of f -> c :
            - Add c to C
      Else :
         - Break
   - Send the list of the chunk to everyone. (The received responses will be compared against C)
   - Wait 'TimeBetweenChunksUpdate' - (Time.now - t)

Parameters

Most parameters will be stored as constants in their component.

Name Value Unit Explanation/Comments
IMAliveFrequency 0.1 [Hz] The message IMAlive is sent each 10s.
ChunkSize 33554432 [Byte] (32 MB)
LanSpeed 52428800 [Byte/s] (50 MB/s)
TimeRecheckChunkFactor 4 - If the time to download a chunk exceeds TimeRecheckChunkFactor * ChunkSize / LanSpeed the peers are rescanned to choose a better one (better download rate). For example : 4 * 32 / 50 = 2.6 second
SwitchToAnotherPeerFactor 1.5 - During the recheck of the peers to choose a better one the other download rate must be above the current * 1.5.
DownloadRateValidTime 1500 / LanSpeed = 300 s [s] (5 min). The download rate of a peer is only valid during this time after its last update. After that its rate is set to the maximum.
TimeBetweenChunksUpdate 500 / LanSpeed = 10 s [s] Each 10 s a daemon will scan the NumberOfChunkToUpdate first chunks from the first queued downloads to know which peer has which chunk.
NumberOfChunkToUpdate 100 * LanSpeed / ChunkSize = 156 - The first 156 hash chunks (3 kB) will by send periodically to each peer. See message HaveChunks in the proto file.
FindTimeout 15 [s] A search request is abandoned after 15 seconds from the start of the request. See message Find.
GetHashesTimeout 200 [s] Timeout for the message GetHashes.
HaveChunksTimeout TimeBetweenChunksUpdate = 10 [s] Timeout for the message HaveChunks.
GetEntriesTimeout 10 [s] Timeout for the message GetEntries.
NbDownloadThread 3 - Number of concurrent downloading thread.
BufferSize 1048576 [Byte] (1 MB). This buffer is used when reading or writing a file.
TCPSocketBufferSize 33554432 [Byte] (32 Mo). Used when data are received. See QAbstractSocket::setReadBufferSize.
TCPPeerConnectionKeepAlive 600 [s] (10 min). There's can be one or more connection to a certain peer, these connections are kept alive for a period of time. For each known peer there is a pool of connection.

Core <-> GUI

Updated by Greg Burri over 15 years ago · 47 revisions