IPN interface to protocol modules

From Virtualsquare
Revision as of 19:26, 27 December 2012 by Renzo (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search
struct ipn_protocol {
  int refcnt;
  int (*ipn_p_newport)(struct ipn_node *newport);
  int (*ipn_p_handlemsg)(struct ipn_node *from,struct msgpool_item *msgitem, int depth);
  void (*ipn_p_delport)(struct ipn_node *oldport);
  void (*ipn_p_postnewport)(struct ipn_node *newport);
  void (*ipn_p_predelport)(struct ipn_node *oldport);
  int (*ipn_p_newnet)(struct ipn_network *newnet);  
  int (*ipn_p_resizenet)(struct ipn_network *net,int oldsize,int newsize);
  void (*ipn_p_delnet)(struct ipn_network *oldnet);
  int (*ipn_p_setsockopt)(struct ipn_node *port,int optname,
      char __user *optval, int optlen);
  int (*ipn_p_getsockopt)(struct ipn_node *port,int optname,
      char __user *optval, int *optlen);
  int (*ipn_p_ioctl)(struct ipn_node *port,unsigned int request,
      unsigned long arg);

int ipn_proto_register(int protocol,struct ipn_protocol *ipn_service);
int ipn_proto_deregister(int protocol);

void ipn_proto_sendmsg(struct ipn_node *to, struct msgpool_item *msg, int depth);

A protocol (sub) module must define its own ipn_protocol structure (maybe a global static variable).

ipn_proto_register must be called in the module init to register the protocol to the IPN core module. ipn_proto_deregister must be called in the destructor of the module. It fails if there are already running networks based on this protocol.

Only two fields must be initialized in any case: ipn_p_newport and ipn_p_handlemsg.

ipn_p_newport is the new network node notification. The return value is the port number of the new node. This call can be used to allocate and set private data used by the protocol (the field proto_private of the struct ipn_node has been defined for this purpose).

ipn_p_handlemsg is the notification of a message that must be dispatched. This function should call ipn_proto_sendmsg for each recipient. It is possible for the protocol to change the message (provided the global length of the packet does not exceed the MTU of the network). Depth is for loop control. Two IPN can be interconnected by kernel cables (not implemented yet). Cycles of cables would generate infinite loops of packets. After a pre-defined number of hops the packet gets dropped (it is like EMLINK for symbolic links). Depth value must be copied to all ipn_proto_sendmsg calls. Usually the handlemsg function has the following structure:

static int ipn_xxxxx_handlemsg(struct ipn_node *from, struct msgpool_item *msgitem, int depth)
 /* compute the set of receipients */
 for (/*each receipient "to"*/)

It is also possible to send different packets to different recipients.

struct msgpool_item *newitem=ipn_msgpool_alloc(from->ipn);
/* create a new contents for the packet by filling in newitem->len and newitem->data */

(please remember to call ipn_msgpool_put after the sendmsg of packets allocated by the protocol submodule).

ipn_p_delport is used to deallocate port related data structures.

ipn_p_postnewport and ipn_p_predelport are used to notify new nodes or deleted nodes. newport and delport get called before activating the port and after disactivating it respectively, therefore it is not possible to use the new port or deleted port to signal the change on the net itself. ipn_p_postnewport and ipn_p_predelport get called just after the activation and just before the deactivation thus the protocols can already/still send packets on the network.

ipn_p_newnet and ipn_p_delnet notify the creation/deletion of a IPN network using the given protocol.

ipn_p_resizenet notifies a number of ports change

ipn_p_setsockopt and ipn_p_getsockopt can be used to provide specific socket options.

ipn_p_ioctl protocols can implement also specific ioctl services.

Personal tools