This header holds generic routines and data structures used for TCP based communication between a framebuffer and a remote process. Variations on this logic, based originally on the stand-alone fbserv program, are at the core of MGED and Archer's ability to display incoming image data from a separate rt process. More...

#include "common.h"
#include "pkg.h"
#include "dm/defines.h"

Include dependency graph for fbserv.h:

This graph shows which files directly or indirectly include this file:

Go to the source code of this file.

Data Structures
struct	fbserv_listener

struct	fbserv_client

struct	fbserv_obj

Macros
#define	NET_LONG_LEN 4
	# bytes to network long More...

#define	MAX_CLIENTS 32

#define	MAX_PORT_TRIES 100

#define	FBS_CALLBACK_NULL (void (*)(void))NULL

#define	FBSERV_OBJ_NULL (struct fbserv_obj *)NULL

Functions
int	fbs_open (struct fbserv_obj *fbsp, int port)

int	fbs_close (struct fbserv_obj *fbsp)

struct pkg_switch *	fbs_pkg_switch (void)

void	fbs_setup_socket (int fd)

int	fbs_new_client (struct fbserv_obj fbsp, struct pkg_conn pcp, void *data)

void	fbs_existing_client_handler (void *clientData, int mask)

Detailed Description

This header holds generic routines and data structures used for TCP based communication between a framebuffer and a remote process. Variations on this logic, based originally on the stand-alone fbserv program, are at the core of MGED and Archer's ability to display incoming image data from a separate rt process.

Asynchronous interprocess communication and event monitoring is (as of 2021) still very much platform and toolkit specific. Hence, these data structures contain some void pointers which are used by individual applications to connect their own specific methods (for example, Tcl_Channel) to handle this problem. Improving this to be more generic and less dependent on specific toolkits and/or platform mechanisms would be a laudable goal, if practical.

Definition in file fbserv.h.

Data Structures

Macros

Functions

Detailed Description