It is this application that takes incoming messages from a node, and will send each message to the designated other node.
Since this is the "core" of the Sofa Switch sytem, we have included a description of the messsaging protocol, and some examples of the messaging protocol in use.
| Manager | listens for incoming TCP connect requests, and spawns/deletes instances of the TcpConnection class as required. |
| Manager::ConnectionDict | a threadsafe list of all the active instances of the TcpConnection class. |
| ServerProcess | the core class that handles the command line and launches this app. This class does the initialization for various pwlib background functions, and contains a wrapper for the int main(int argc, char **argv); |
| TcpConnection | The class responsible for handling all comms with one remote node |
| TcpConnectionList | A list of instances of the TcpConnection class, which have been prebuilt and are ready for use. By having them prebuilt, we can more quickly create a new connection for each incoming request |
The key component in this application is the TcpConnection class. An instance of the TcpConnection class is created when an incoming TCP request from some remote node is detected. The created class handles all messages to/from that remote node. Each TcpConnection class consists of one thread, that sits waiting to handle incoming messages.
This application handles a list of TcpConnection instances. The list is as long as the number of connected remote nodes. The thread safe mechanism in PwLib is used to maintain this list (Manager::ConnectionDict).
One TcpConnection instance may write to any other TcpConnection instance, via the bookkeeping of Manager::ConnectionDict. Given this, it is possible for a message to come in via one TcpConnection instance, and go out another. It is possible for a remote node to send a message to itself - there is no check for schizophrenic remote nodes (remote nodes that wish to talk to themselves). Sending a message to oneself is helpful, as it verifies the server is, at least, "mostly working".
When the TCP connection ends, the thread associated with that particular TcpConnection instance ends. On thread end, pwlib's deletion processes are started, and the TcpConnection instance is deleted.
1.4.6