[olsr-dev] new ipc

Lorenz Schori (spam-protected)
Thu Mar 9 13:54:38 CET 2006


hi all

i did sacrifice some days of my vacencies and put together some basic  
code and a concept for the new ipc mechanism. at the moment i did not  
care about how data will come from the client to olsrd and back - i  
simply assume plain ascii, so the protocol itself is still open for  
discussion.

currently the whole stuff is packed into a hijacked httpinfo plugin.  
for production it will have to move into olsrd itself in order to  
make the symbols available everywhere.

the icp system consists of the following parts:
targets: addressable parts of olsrd or plugins.
actions/parameter: actions which can be sent to targets. actions can  
have multiple paramters of different types.
session: a client session which consists of a list of actions.

targets, actions and paramters are identified by a string value, the  
selector. targets can contain actions and actions can contain  
paramters. each of them has to be registered with the ipc system with  
the following functions:
ipc_target_spec* icp_register_target_spec_once(char* selector);
ipc_action_spec* icp_register_action_spec_once(char* selector,  
ipc_target_spec*);
ipc_param_spec* icp_register_param_spec_once(char* selector,  
ipc_action_spec*, char type);

as soon as the appropriate specs are registered with the ipc system a  
target can adopt a handler for an action:
int ipc_adopt_action_handler(ipc_target_spec* target,
                          ipc_action_spec* action,
                          ipc_action_handler handler,
                          void* user_info);

some sort of protocol will now allow the client to send commands to  
targets using target+action+parameter selectors with a session. each  
session contains a list of actions which are created using the  
appropriate xxx_spec structures.

ipc_action*
ipc_session_add_action(ipc_session* session, ipc_action_spec* spec,  
ipc_target_spec* target);

ipc_param*
ipc_action_add_param(ipc_action* action, ipc_param_spec* spec, void*  
data, int size, int flags);

as soon the session is ready it is executed by:
int ipc_session_perform(ipc_session* session);
this function loops several times thru the whole action list, each  
time incrementing its session state from init thru header, body,  
footer then fini and finally eos (end of session). this allows action  
handlers to react in one or more states of the session. if the  
session is in header, body or footer state data can be sent to it using

int
ipc_send_session(ipc_target_spec *target, char* string, int size,  
ipc_session* session);

to simplify monitoring tasks for olsr messages there is a function  
which installs a default handler for the monitoring action for a  
given target. this handler will install a parser function and call  
the formatter function for each incomming olsr message of the  
specified type as long as there are interested clients:
int
ipc_adopt_target_olsr_formatter(ipc_target_spec* target,
                                 olsr_u8_t olsr_msgtype,
                                 ipc_olsr_formatter,
                                 void* user_info);
note: targets can only have ONE formatter.

there is much missing in the code and there are major bugs for sure.  
just want to gather some feedback on the concept and the code so i  
can estimate if its worth working further on it. someone interested  
in cooperation?

lorenz

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ipc.zip
Type: application/zip
Size: 18782 bytes
Desc: not available
URL: <http://lists.olsr.org/pipermail/olsr-dev/attachments/20060309/ad9e349e/attachment.zip>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: Signierter Teil der Nachricht
URL: <http://lists.olsr.org/pipermail/olsr-dev/attachments/20060309/ad9e349e/attachment.sig>


More information about the Olsr-dev mailing list