Player: the meta-device. More...

Detailed Description

Player: the meta-device.

The player device represents the server itself, and is used in configuring the behavior of the server. There is only one such device (with index 0) and it is always open.

Todo:: Determine what, if any, data delivery modes and requests are needed.

#define	PLAYER_PLAYER_REQ_DEVLIST 1
	Request/reply subtype: get device list.

#define	PLAYER_PLAYER_REQ_DRIVERINFO 2
	Request/reply subtype: get driver info.

#define	PLAYER_PLAYER_REQ_DEV 3
	Request/reply subtype: (un)subscribe to device.

#define	PLAYER_PLAYER_REQ_DATA 4
	Configuration request: Get data. More...

#define	PLAYER_PLAYER_REQ_DATAMODE 5
	Request/reply subtype: get device list.

#define	PLAYER_PLAYER_REQ_AUTH 7
	Request/reply subtype: get device list.

#define	PLAYER_PLAYER_REQ_NAMESERVICE 8
	Request/reply subtype: get device list.

#define	PLAYER_PLAYER_REQ_ADD_REPLACE_RULE 10
	Request/reply subtype: get device list.

#define	PLAYER_PLAYER_SYNCH_OK 1
	Request/reply subtype: get device list.

#define	PLAYER_PLAYER_SYNCH_OVERFLOW 2
	Request/reply subtype: get device list.

#define	PLAYER_OPEN_MODE 1
	Device access mode: open.

#define	PLAYER_CLOSE_MODE 2
	Device access mode: close.

#define	PLAYER_ERROR_MODE 3
	Device access mode: error.

#define	PLAYER_DATAMODE_PUSH 1
	Data delivery mode: Send data from all subscribed devices all the time (i.e. More...

#define	PLAYER_DATAMODE_PULL 2
	Data delivery mode: Only on request, send data from all subscribed devices. More...

#define	PLAYER_PLAYER_MSG_REPLACE_RULE_ACCEPT 0
	A replace rule can either accept, replace or ignore a message. More...

#define	PLAYER_PLAYER_MSG_REPLACE_RULE_REPLACE 1
	Request/reply subtype: get device list.

#define	PLAYER_PLAYER_MSG_REPLACE_RULE_IGNORE 2
	Request/reply subtype: get device list.

typedef struct player_device_devlist	player_device_devlist_t
	Request/reply: Get the list of available devices. More...

typedef struct player_device_driverinfo	player_device_driverinfo_t
	Request/reply: Get the driver name for a particular device. More...

typedef struct player_device_req	player_device_req_t
	Request/reply: (un)subscribe to a device. More...

typedef struct player_device_datamode_req	player_device_datamode_req_t
	Configuration request: Change data delivery mode. More...

typedef struct player_device_auth_req	player_device_auth_req_t
	Configuration request: Authentication. More...

typedef struct player_device_nameservice_req	player_device_nameservice_req_t
	Nameservice request. More...

typedef struct player_add_replace_rule_req	player_add_replace_rule_req_t
	Configuration request: Add client queue replace rule. More...

Macro Definition Documentation

◆ PLAYER_DATAMODE_PULL

#define PLAYER_DATAMODE_PULL 2

Data delivery mode: Only on request, send data from all subscribed devices.

A PLAYER_MSGTYPE_SYNCH packet follows each set of data. Request should be made automatically by client libraries when they begin reading.

◆ PLAYER_DATAMODE_PUSH

#define PLAYER_DATAMODE_PUSH 1

Data delivery mode: Send data from all subscribed devices all the time (i.e.

when it's ready on the server).

◆ PLAYER_PLAYER_MSG_REPLACE_RULE_ACCEPT

#define PLAYER_PLAYER_MSG_REPLACE_RULE_ACCEPT 0

A replace rule can either accept, replace or ignore a message.

◆ PLAYER_PLAYER_REQ_DATA

#define PLAYER_PLAYER_REQ_DATA 4

Configuration request: Get data.

When the server is in a PLAYER_DATAMODE_PULL data delivery mode, the client can request a single round of data by sending a zero-argument request with type code PLAYER_PLAYER_REQ_DATA. The response will be a zero-length acknowledgement.

Typedef Documentation

◆ player_add_replace_rule_req_t

typedef struct player_add_replace_rule_req player_add_replace_rule_req_t

Configuration request: Add client queue replace rule.

Allows the client to add a replace rule to their server queue. Replace rules define which messages will be replaced when new data arrives. If you are not updating frequently from ther server then the use of replace rules for data packets will stop any queue overflow messages

Each field in the request type corresponds to the equivalent field in the message header use -1 for a dont care value.

◆ player_device_auth_req_t

typedef struct player_device_auth_req player_device_auth_req_t

Configuration request: Authentication.

Todo:: Add support for this mechanism to libplayertcp. Right now, it's disabled.

If server authentication has been enabled (by providing '-key <key>' on the command-line); then each client must authenticate itself before otherwise interacting with the server. To authenticate, send a request with this format.

If the key matches the server's key then the client is authenticated, the server will reply with a zero-length acknowledgement, and the client can continue with other operations. If the key does not match, or if the client attempts any other server interactions before authenticating, then the connection will be closed immediately. It is only necessary to authenticate each client once.

Note that this support for authentication is NOT a security mechanism. The keys are always in plain text, both in memory and when transmitted over the network; further, since the key is given on the command-line, there is a very good chance that you can find it in plain text in the process table (in Linux try 'ps -ax | grep player'). Thus you should not use an important password as your key, nor should you rely on Player authentication to prevent bad guys from driving your robots (use a firewall instead). Rather, authentication was introduced into Player to prevent accidentally connecting one's client program to someone else's robot. This kind of accident occurs primarily when Stage is running in a multi-user environment. In this case it is very likely that there is a Player server listening on port 6665, and clients will generally connect to that port by default, unless a specific option is given.

This mechanism was never really used, and may be removed.

◆ player_device_datamode_req_t

typedef struct player_device_datamode_req player_device_datamode_req_t

Configuration request: Change data delivery mode.

The Player server supports two data modes, described above. By default, the server operates in PLAYER_DATAMODE_PUSH mode. To switch to a different mode send a request with the format given below. The server's reply will be a zero-length acknowledgement.

◆ player_device_devlist_t

typedef struct player_device_devlist player_device_devlist_t

Request/reply: Get the list of available devices.

It's useful for applications such as viewer programs and test suites that tailor behave differently depending on which devices are available. To request the list, send a null PLAYER_PLAYER_REQ_DEVLIST.

◆ player_device_driverinfo_t

typedef struct player_device_driverinfo player_device_driverinfo_t

Request/reply: Get the driver name for a particular device.

To get a name, send a PLAYER_PLAYER_REQ_DRIVERINFO request that specifies the address of the desired device in the addr field. Set driver_name_count to 0 and leave driver_name empty. The response will contain the driver name.

◆ player_device_nameservice_req_t

typedef struct player_device_nameservice_req player_device_nameservice_req_t

Nameservice request.

Todo:: Update this structure and add support for it to libplayertcp. Right now it's disabled.

◆ player_device_req_t

typedef struct player_device_req player_device_req_t

Request/reply: (un)subscribe to a device.

This is the most important request! Before interacting with a device, the client must request appropriate access. Valid access modes are:

PLAYER_OPEN_MODE : subscribe to the device. You will receive any data published by the device and you may send it commands and/or requests.
PLAYER_CLOSE_MODE : unsubscribe from the device.
PLAYER_ERROR_MODE : the requested access was not granted (only appears in responses)

To request access, send a PLAYER_PLAYER_REQ_DEV request that specifies the desired device address in the addr field and the desired access mode in access. Set driver_name_count to 0 and leave driver_name empty. The response will indicate the granted access in the access field and the name of the underyling driver in the driver_name field. Note that the granted access may not be the same as the requested access (e.g., if initialization of the driver failed).