net/dctc is a Direct Connect™ client. Amongst its advanced features are both bandwidth throttling and multiple part file download from multiple hubs. It employs a combination of multi-thread and multi-process programming models to achieve its goals.
It uses one process for each Direct Connect™ hub it connects to. These processes use semaphores to insure that all processes are correctly synchronized so that all processes bandwidth usage summed up do not surpass user chosen bandwidth limits.
On a per process basis, there are threads. One thread communicates with the hub while other thread manages bandwidth throttling. It periodically checks the overall bandwidth usage of the summed concurring processes throttling its process accordinly.
A blocking call is a call that blocks while waiting for a request to be serviced. Blocking calls block the whole process.
Some blocking calls can be told not to block if a request cannot be serviced right away. In case these fail, they signal if they would have blocked otherwise so that appropriate action can be taken.
Situation when a cooperative group of processes wait for an event to be triggered by a member (or members) of the same group that will never occur. It requires external action for its resolution.
Semaphores work as barriers, providing an effective exclusion mechanism for disputed resources. If a resource is available, a semaphore atomically both allows access to the resource and signals that it is being used; thus, avoiding undesireable sharing of it. However, if the resource is not available, a semaphore may block waiting for it to become available. Therefore, when working in this manner, semaphores behave as blocking calls.
There are 2 major paths to implement multi-threading:
Each thread of a given program is ran on a separate process.
This is the model of both Linux and Solaris operating systems.
All threads of a given program are ran inside a single process. The widely known user space threads implementation work this way.
This is the model of FreeBSD, NetBSD and OpenBSD; among others.
net/dctc utilizes semaphores within each process to manage throttling cooperation amidst concurrent processes. Furthermore, each process has concurrent threads which manage throttling on a per process basis. Whenever a thread within the process accesses a semaphore to verify the current bandwidth usage of all other processes, it may block. This might lead to a deadlock scenario.
For instance, pretend there is only one process running. It still has to both update and check bandwidth usage. Moreover, it has to check if other processes exist so that it can cooperate with them. Nevertheless, suppose one thread checks the semaphore then another thread from the same program tries to obtain the semaphore, it might block. This is specially true with upload bandwidth limitting.
This is of importance since we are working with multiple threads. I have mentioned 2 threading models. Recall that a blocking call blocks the whole process. Consequently, the semaphore will block a single thread in model 1. Nonetheless, it will effectively block ALL threads of the program in model 2 since it will block the process containing all threads of the program.
Therefore, blocking calls should be avoided in multi-threaded scenarios since it is not guaranteed that using a blocking call will not block ALL threads instead of only the calling thread. This affects all BSD implementations. Of course, blocking calls can still be used if the programmer plans carefully for this.
Whenever an upload would begin, net/dctc would block in a semwait state requiring a kill(1) command invocation.
Hide Absolute paths is a net/dctc option to hide the leading / in a directory absolute reference when returning search results. Also, it prefixes all search results with character ÿ. Besides, it also triggers removal of leading / when building the available file database if enabled.
However, when checking if a file requested for upload is available with
inside src/dc_manage.c, files should be processed to remove the leading ÿ if hide absolute is enabled. Since this does not happen, all upload requests do not work except for the available file list (dcflist).For questions about FreeBSD, read the <documentation>.
For questions about the FreeBSD ports
system, e-mail <ports@FreeBSD.org>.
For questions about this documentation, e-mail <lioux@FreeBSD.org>.