doc/html/devel/devref.html
3proxy is implemented as multithread application. Server model is implemented as "one connection – one thread". It means, for every client connection new thread is created. This model is effective enough under Windows, because it allows it avoid thread creation on asynchronous operations, yet under most POSIX systems this model can not be considered as most efficient. It's planned for (very far in future) release to implement more efficient model, where single thread can serve few clients.
3proxy begins with main thread. This thread parses configuration file and starts main loop. During configuration file parsing struct extaparam conf; structure is filled and service threads are started.
Service threads are started immediately, than service command (e.g. 'proxy' or 'socks') are found during configuration file parsing. Each command creates new thread. Thread does these tasks:
Client threads are started from service thread. Client thread:
Hacking into 3proxy code with plugins
3proxy plugin is any dynamic/shared library. There is no specific requirement for plugin, actually you can load any dynamic library with 'plugin' command. No linking with any libraries are required. However, to interoperate with 3proxy dynamic library must have an export function 3proxy may call to pass the structure with required information.
Because there is no linking between 3proxy and plugin, all 3proxy functions and structures are passed with pluginlink structure. Pluginlink is actually a collection of pointers to 3proxy internal structures and functions. Because pluginlink is constantly extending, you should see it's definitions in structures.h.
There are few points you can get control for your plugin, after it's loaded with 'plugin' command.