player
[Interface specifications]
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_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. | |
#define | PLAYER_DATAMODE_PULL 2 |
Data delivery mode: Only on request, send data from all subscribed devices. | |
#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 |
Device access mode: open. | |
#define | PLAYER_PLAYER_REQ_DATAMODE 5 |
Device access mode: open. | |
#define | PLAYER_PLAYER_REQ_AUTH 7 |
Device access mode: open. | |
#define | PLAYER_PLAYER_REQ_NAMESERVICE 8 |
Device access mode: open. | |
#define | PLAYER_PLAYER_REQ_IDENT 9 |
Device access mode: open. | |
#define | PLAYER_PLAYER_REQ_ADD_REPLACE_RULE 10 |
Device access mode: open. | |
typedef player_device_devlist | player_device_devlist_t |
Request/reply: Get the list of available devices. | |
typedef player_device_driverinfo | player_device_driverinfo_t |
Request/reply: Get the driver name for a particular device. | |
typedef player_device_req | player_device_req_t |
Request/reply: (un)subscribe to a device. | |
typedef player_device_data_req | player_device_data_req_t |
Configuration request: Get data. | |
typedef player_device_datamode_req | player_device_datamode_req_t |
Configuration request: Change data delivery mode. | |
typedef player_device_auth_req | player_device_auth_req_t |
Configuration request: Authentication. | |
typedef player_device_nameservice_req | player_device_nameservice_req_t |
Nameservice request. | |
typedef player_add_replace_rule_req | player_add_replace_rule_req_t |
Configuration request: Add client queue replace rule. |
Define Documentation
|
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. |
|
Data delivery mode: Send data from all subscribed devices all the time (i.e. when it's ready on the server). |
Typedef Documentation
|
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. |
|
Configuration request: Authentication.
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. |
|
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 |
|
Configuration request: Change data delivery mode.
The Player server supports two data modes, described above. By default, the server operates in |
|
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. |
|
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. |
|
Nameservice request.
|
|
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:
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). |