Following is over-all torrent client design I can think of :
bittorrent_design.jpg [ 238.53 КБ | 2761 просмотр ]
: GUI of application and consumes one threadBackEnd.asm
: Daemon/Backend of torrent application and consumes two thread
FronEnd and BackEnd communicates through network sockets over TCP protocol via server[backend]-client[frontend] mechanism.
TCP Protocol payload format [from frontend -> backend] is :
Type of Message can be :
TORRENT_ADD(1) (Payload : Torrent_ID : Torrent File Path : Download Location)
TORRENT_START(2) (Payload : Torrent_ID)
TORRENT_PAUSE(3) (Payload : Torrent_ID)
TORRENT_REMOVE(4) (Payload : Torrent_ID)
TORRENT_SHOW(5) (Payload : Torrent_ID)
TORRENT_QUIT(6) (This message closes backend)
TCP Protocol Payload format for messages[ from backend -> frontend ] is :
There is only one thread which draws UI as well as connects with backend and updates it.In backend :
Thread one handles all incoming request from frontend and provides neccessary information.
Thread two handles all torrents' downlaoding and uploading.
These two threads of backend share one common data-area [/list] : List of Torrents.
Thread one mainly consumes this list and add/remove torrents
Thread two mainly updates this list.
Each element of list follows torrent structure described in torrent.inc [Few entries like torrent_id , is yet to be made]
-> Thread two loops over all torrents in torrent list.
-> For each torrent, it works for every torrernt for around 5000ms. [this time is subject to experiment and yet to optimize].
-> For each torrent, it connects with tracker server [if timeout is happended for connecting with tracker server , which is usually 1800 secs (30 mins)]
it connects with all active peers, offering pieces to download.
it sends keep-alive messages to inactive peers [2 minute is max ideal period] or close connection with them.
it accepts incoming connections from other peers [at max 16 peers needs to be handled , according to torrent guideline ] and uploads pieces to them.
-> Uploading and downloading starts at two timeout events within 5000 ms span. Credits :
-> Idea of using network socket over IPC mechanism is conclusion of discussion with Dunkaist.
Benefit of using network socket over IPC , is , that we can have backend and frontend on two different kolibrios boxes.
-> Keeping thread numbers as minimal as possible is conclusion of discussion with Hidnplayr.
As kolibrios , as a whole , supports only 256 threads.
-> Keeping timeouts for handling multiple connections is also concluson of discussion with Hidnplayr.
So that fairness can be ensured.Help required :
-> Currently I am not able to connect backend with frontend using localhost as IP [127.0.0.1]. My program gets stuck at connect system call with interrupt 40h [provided server is up]. Any help ?
-> I have attached sample tcp-server and tcp-client programs for the same.
tcp_client.asm [3.45 КБ]
tcp_server.asm [4.65 КБ]
-> Currently, I am able to open file browser dialog and copies a path of selected file to editbox.
-> Problem, I am facing is : I am not able to select folder. [I need this for download location of torrent]. I guess it has something to do with filter of open dialog.Current Progress :
-> I am able to download one piece-block from peer.
-> Basic structure of GUI is almost ready and I am much clear regarding the over-all design.
Github Link : https://github.com/chokshiutsav/bittorrent
Suggestion regarding any desing aspect is welcome.