1. you launch a plugin using a shell command like plugin_name protocol# connexion_file plugin_port trustpeer_port
connexion_file is the filename of a plugin connexion informations, each plugin has a different structure for this file (this file is
what one of your friends will give you, and you will give him one too). Each connexion_file should begin by a line with the name of the plugin, then a line with the version # of the data structure used in this file
plugin_port will be the port # of the local plugin server socket
trustpeer_port is the actual # of the local trustpeer server socket
It means main() takes 4 parameters
main() will return error code 3 if the plugin server socket port is already busy
and error code ERRNORM (i.e. 2) if other connexion_file informations are incorrect
Any other unexpected error will be a programming error, with error informations written on stderr, and main () will return ERRPROG (i.e. 1)
- If plugin_name contains tcptp (like our example plugin
stone_tcptp.sh) then TCP is used instead of UDP for communications between Trustpeer and the Plugin
2. each plugin must be able to open client sockets and server sockets on localhost
Each local server socket from plugin A on machine A will transmit all informations to plugin B on machine B, using the plugin internal protocol.
The plugin B will open a client socket on machine B to communicate with trustpeer B and transmit all informations with no modification
3. since each plugin is an independent process, plugin A can keep alive a connexion with plugin B, sending dummy packets to fool traffic analysis tools
4. it means our plugin interface is language/platform independent, since all platforms do have udp/tcp sockets now
5. it means that every socket based tunneling program (stunnel, stone, ...) can be used to make a plugin easily
see our simple stone-ssl based
stone_simple_tcptp.sh