Browse Prior Art Database

A Scheduling Algorithm for Transfering smaller sized files faster than Larger sized files for multithreaded data transfer applications

IP.com Disclosure Number: IPCOM000015297D
Original Publication Date: 2001-Dec-13
Included in the Prior Art Database: 2003-Jun-20

Publishing Venue

IBM

Abstract

1.0 A Scheduling algorithm for transmitting files of smaller sizes faster than larger sized files. 1.1 Introduction This algorithm below describes a method of scheduling different threads of a multi-threaded TFTP server (where a separate thread handles each client request) so that the smaller requests get higher priority. The benchmarking tests stated below also indicate that the tests done with various file sizes indicate that the algorithm works as per design. The illustration is done with a TFTP server implementation, which has the File Size transfer option negotiation. 1.2 Overview of the algorithm

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 19% of the total text.

Page 1 of 17

  A Scheduling Algorithm for Transfering smaller sized files faster than Larger sized files for multithreaded data transfer applications

  1.0 A Scheduling algorithm for transmitting files of smaller sizes faster than larger sized files.

1.1 Introduction

This algorithm below describes a method of scheduling different threads of a multi-threaded TFTP server (where a separate thread handles each client request) so that the smaller requests get higher priority. The benchmarking tests stated below also indicate that the tests done with various file sizes indicate that the algorithm works as per design. The illustration is done with a TFTP server implementation, which has the File Size transfer option negotiation.

1.2 Overview of the algorithm

As noted before the program will start a new thread to handle each of the incoming requests. Now to improve the performance of the TFTP server with respect to smaller file size requests, we need to keep track of how much of a file has been sent at a given point of time or this purpose we will keep a global data structure, which will store the amount of file sent for each of the connections currently in progress. Now for such a structure we will use a linked list. The name of the list will be TransferList.

The structure of the list will be as follows, class TTransferInfo
{


pthread_t tid;
int t_priority; //Stores the threads current priority int t_age;
bool t_Execute; //a Boolean flag indicating whether thread should stop executing. bool t_Manual; // Indicates whether this thread is under direct control of the adminstrator int frem; // Number of bytes remaining char m_Path[200]; //Stores the file name being transferred.

}

list<TTransferInfo*> TransferList; Following are some preconditions that must be satisfied before the scheduler can start scheduling

* Every time a new read/write request is initiated, an entry will be made by the thread handling the client into this list (t_tid field in the list), and every time a block of data is sent, the thread will update its entry in the list to reflect the number of bytes remaining.(frem field)

* When the entire file has been sent the thread will remove its entry from the list. This ensures that the scheduler thread does not try to schedule a non-existent thread.

* Every time the TransferList is accessed, the thread wanting to do so would need to acquire a mutex called TransferMutex before it is able to manipulate the list. This will ensure that the thread does not corrupt the list while

1

Page 2 of 17

another thread is manipulating it.
* The scheduler will run as a separate thread created at server startup. This thread will wake up after every 600ms , and schedule the threads according to the algorithm defined below.

1.3 Scheduling of threads

* The algorithm will use condition variables for synchronization of the various threads. When the server starts , it will create a condition variable say CondVariable and an associated mutex say CondMutex.

* These two object...