The server data structures consist of struct's that define the contents of packets, as well as protocol constants. For the UDP server routines, some extra data structures to holding leasing information are also defined.
The data structures common to all server types are:
/* Peep protocol packet */
typedef struct {
unsigned char version; /* major protocol version */
unsigned char type; /* type of packet */
unsigned char content; /* contents format */
char reserved[5]; /* reserved */
int magic; /* magic number for checking */
int len; /* length of the contents */
} HEADER;
/* Holder structure for the packet */
typedef struct {
HEADER header; /* packet header */
void *body; /* body of the actual message */
} PACKET;
/* PACKET body types */
typedef char * XML_BUFFER;
typedef EVENT EVENT_BODY;
typedef char * MSG_STRING;
typedef struct broadcast {
int port;
struct broadcast *next;
} BROADCAST;
When using UDP only, some extra data structures are defined in udp_server.h:
/* Peep leasing is a very low resolution leasing and is not meant to be
* used for long periods of time. After lease time has expired, the
* information associated with the broadcast should be considered
* obsolete
*/
struct lease {
unsigned char min;
unsigned char sec;
};
/* The entry in the linked list database of active clients */
struct leaselist {
struct in_addr host; /* The ip address of the active host */
unsigned int port; /* The port to address the host with */
struct timeval expired; /* The time remaining at which this
* has expired
*/
struct leaselist *nextent; /* The next entry in the list */
};
/* Definition for body of a packet whose sole purpose is to send
* leasing information
*/
typedef struct {
struct lease lease;
} LEASE_BODY;
/* Definition of a packet body for sending both lease information
* and ID information
*/
typedef struct {
struct lease lease;
int len;
char *id;
} UDP_BROADCAST_BODY;
All Peep packets contain a header structure as defined in the HEADER struct and a variable body type. The version field of the header is used to differntiate versions of the protocol and will mostly likely change with future versions. The type field indicates the purpose of the packet. In the Peep protocol, packets can have the following purposes, as defined by protocol constants in server.h:
0)
1)
2)
In addition, the UDP only communication scheme defines some extra protocol constants in udp_server.h:
3)
4)
The content field of the packet indiciates how the packet content has been laid out. Different packet contents are appropriate for different packet types. There are three defined packet types as evidenced by the typdef's in the header. They are:
0)
1)
2)
Again, the UDP only communication scheme defines some extra packet types for containing lease information in udp_server.h:
3)
4)
When staring up, the server constructs a BROADCAST packet and sets the packet type and packet content type accordingly. It constructs a string containing a list of its peep classes from configuration information found in peep.conf and delimites them with a ''!''. If leasing is being used, it also constructs a lease time which is based on the leasing constants set in udp_server.h. There are two lease constants: one set tells the client when to consider the server non-functional, and the other when the server should renew its lease with the clients.
One the clients and servers have discovered each other, further messaging takes place via direct communication over the protocol of choice. With TCP and SSL, a session is established and a separate server thread is spawned to handle the new session. With UDP, leasing information is sent via direct communication with servers on top of event information.
In the UDP only scheme, because the servers and clients broadcast only once upon startup, the server maintains a list of clients using the leaselist struct. After the server starts up and broadcasts its existence and the appropriate clients respond that they're alive, the server adds the client into the lease list. Similarly, when the clients start up, theya re given lease information and added into the lease list. The server also records the time when the client entry will expire. If the server doesn't hear from the client after the lease time has elapsed, it removes the entry from the hostlist. An alarm is scheduled at an even interval to scan the lease list and purge any expired entries.
Finally, when a client event is received, the server performs any processing needed on the packet, and places an EVENT defined in engine.h into the engine queue. In the case of an XML event, the XML data is parsed and fed into the server code hook for post processing.