| SIP Express Router v0.8.8 - Developer's Guide | ||
|---|---|---|
| <<< Previous | Next >>> | |
Upon startup, all children execute recvfrom function. The process will enter the kernel mode. When there is no data to be processed at the moment, the kernel will put the process on list of processes waiting for data and the process will be put asleep.
When data to be processed was received, the first process on the list will be removed from the list and woken up. After the process finished processing of the data, it will call recvfrom again and will be put by the kernel at the end of the list.
When next data arrives, the first process on the list will be removed, processes the data and will be put on the end of the list again. And so on...
The main loop logic can be found in function udp_rcv_loop in file udp_server.c.
The message is received using recvfrom function. The received data is stored in buffer and zero terminated.
If configured so, basic sanity checks over the received message will be performed.
The message is then processed by receive_msg function and recvfrom is called again.
The function can be found in receive.c file.
In the server, a request or response is represented by sip_msg structure. The structure is allocated in this function. The original message is stored in buf attribute of the structure and is zero terminated. Then, another copy of the received message will be created and the copy will be stored in orig field. The original copy will be not modified during the server operation. All changes will be made to the copy in buf field. The second copy of the message will be removed in the future.
The message will be parsed (function parse_msg). We don't need the whole message header to be parsed at this stage. Only the first line and first Via header need to be parsed. The server needs to know if the message is request or response - hence the first line. The server also needs the first Via to be able to add its own Via - hence the first Via. Nothing else will be parsed at the moment - this saves time. (Message parser as well as sip_msg structure will be described later).
A module may register callbacks. Each callback have associated an event, that will trigger the callback. One such callback is pre-script callback. Such callback will be called immediatelly before the routing part of the config file will be executed. If there are such callbacks registered, they will be executed now.
As the next step we will determine type of the message. If the message being processed is a REQUEST then basic sanity checks will be performed (make sure that there is the first Via and parsing was successfull) and the message will be passed to routing engine. The routing engine is one of the most complicated parts of the server and will be in detail described in chapter The Routing Engine.
If the message is a RESPONSE, it will be simply forwarded to its destination.
After all, post-script callbacks will be executed if any and the structure representing the message will be released.
Processing of the message is done now and the process is ready for another SIP message.
| <<< Previous | Home | Next >>> |
| Forking | The Server Shutdown |