Open Ethernet Networking (OpEN) API Guide and Reference Manual
3.6.0.3
|
Applications can register for a variety of events, such as changes to the forwarding table. When an event occurs, RPPI notifies each registered application via messages over a socket. RPPI uses UNIX domain datagram sockets. Because both endpoints of a UNIX socket must be on the same system, RPPI only serves applications running on the local system.
Each application is expected to create a socket for each RPPI service of interest. Each service within RPPI sends to a different client address. An application can use a single thread to listen for messages on all sockets, or can assign a listen thread per socket. With separate sockets, a large number of messages for one type of event cannot compromise notifications for another type of event.
Messages for all types of RPPI events use a common format, beginning with a 2-byte message type and 2-byte message length. Message type codes are unique across all RPPI services. The message length is the length of the entire message including the message type and message length fields. All values are in host byte order since both ends are running on the same system.
While event delivery should be very reliable, it is possible that RPPI may fail to deliver an event to an application, or an application may fail to respond to an event in a timely manner, in which case RPPI does not know whether the event was not delivered or the application was unable to process it. Loss of an event may cause state within an application to diverge from the state within ICOS. Therefore, RPPI sends periodic KEEPALIVE messages to let each application know that RPPI considers the application to still be registered and in sync with ICOS state. Each RPPI event service periodically sends a KEEPALIVE message to each registered client. KEEPALIVEs are only sent one way, from RPPI to applications. If an application stops receiving KEEPALIVE messages for a service it has registered for, the application can assume RPPI has detected some problem and RPPI has deregistered the application. The application may reregister for the service and reinitialize its state associated with that service. RPPI detects and deregisters unresponsive applications when they fail to respond to an event.
RPPI uses a non-blocking socket to send messages to applications. If a socket send fails because the send buffer is full, RPPI waits 100 ms and retries. If the second attempt also fails, RPPI drops the message. RPPI services typically deregister an application to which it fails to send a message.