Next Previous Contents

7. Protocol reference

Under some circumstances, it may be preferable to communicate directly with BrlAPI's server rather than using BrlAPI's library. Here are the needed details to be able to do this. This chapter is also of interest if a precise understanding of how the communication stuff works is desired, to be sure to understand how to write multithreaded clients, for instance.

In all the following, integer will mean an unsigned 32 bits integer in network byte order (ie most significant bytes first).

7.1 Reliable packet transmission channel

The protocol between BrlAPI's server and clients is based on exchanges of packets. So as to avoid locks due to packet loss, these exchanges are supposed reliable, and ordering must be preserved, thus BrlAPI needs a reliable packet transmission channel.

To achieve this, BrlAPI uses a TCP-based connection, on which packets are transmitted this way:

The size does not include the { size, type } header, so that packets which don't need any data have a size of 0 byte. The type of the packet can be either of BRLPACKET_* constants defined in api_protocol.h. Each type of packet will be further discussed below.

BrlAPI's library ships two functions to achieve packets sending and receiving using this protocol: brlapi_writePacket and brlapi_readPacket. It is a good idea to use these functions rather than rewriting them, since this protocol might change one day in favor of a real reliable packet transmission protocol such as the experimental RDP.

7.2 Responses from the server

As described below, many packets are `acknowledged'. It means that upon reception, the server sends either:

Some other packets need some information as a response. Upon reception, the server will send either:

If at some point an ill-formed or non-sense packet is received by the server, and BRLPACKET_EXCEPTION is returned, holding the guilty packet for further analysis.

7.3 Operating modes

The connection between the client and the server can be in either of the four following modes:

Termination of the connection is initiated by the client in normal mode by simply closing its side of the socket. The server will then close the connection.

7.4 Details for each type of packet

Here is described the semantics of each type of packet. Most of them are directly linked to some of BrlAPI's library's functions. Reading their online manual page as well will hence be of good help for understanding.

BRLPACKET_AUTHKEY (see brlapi_loadAuthKey())

This must be the first packet ever transmitted from the client to the server. It lets the client authenticate itself to the server. Data is first an integer indicating a protocol version, then comes the authentication key itself.

If the protocol version is not the same as the server's, a BRLERR_PROTOCOL_VERSION error packet is returned and the connection is closed.

If the authentication key matches the servers', it is acknowledged, and other types of packets might be used, other BRLPACKET_AUTHKEY shouldn't be sent by the client.

If the authentication key doesn't match, the server sends a BRLERR_CONNREFUSED and closes the connection.

BRLPACKET_GETDRIVERID (see brlapi_getDriverId())

This should be sent by the client when it needs the 2-char identifier of the current brltty driver. The returned string is \0 terminated.

BRLPACKET_GETDRIVERNAME (see brlapi_getDriverName())

This should be sent by the client when it needs the full name of the current brltty driver. The returned string is \0 terminated.

BRLPACKET_GETDISPLAYSIZE (see brlapi_getDisplaySize())

This should be sent by the client when it needs to know the braille display size. The returned data are two integers: width and then height.

BRLPACKET_GETTTY (see brlapi_getTty())

This should be sent by the client to get control of a tty. Sent data are first a series of integers: the first one gives the number of following integers, which are the numbers of ttys that leads to the tty that the application wants to take control of (it can be empty if the tty is one of the machine's VT). The last integer of this series tells the number of the tty to get control of. Finaly, how key presses should be reported is sent: either a driver name or "", preceded by the number of caracters in the driver name (0 in the case of ""), as an unsigned byte. This packet is then acknowledged by the server.

BRLPACKET_KEY (see brlapi_readKey())

As soon as the client gets a tty, it must be prepared to handle BRLPACKET_KEY incoming packets at any time (as soon as the key was pressed on the braille terminal, hopefuly). The data holds the key or command code as an integer, depending on what has been request in the BRLPACKET_GETTTY packet.

BRLPACKET_SETFOCUS (see brlapi_setFocus())

For the server to know which tty is active, one particular client is responsible for sending BRLPACKET_SETFOCUS packets. They hold a single integer telling the new current tty. For instance, when running an X server on VT 7, the xbrlapi client would have sent a BRLPACKET_GETTTY(7) and will send window IDs whenever X focus changes, allowing display and keypresses switching between xterms.

BRLPACKET_LEAVETTY (see brlapi_leaveTty())

This should be sent to free the tty and masked keys lists. This is acknowledged by the server.

BRLPACKET_IGNOREKEYRANGE, BRLPACKET_UNIGNOREKEYRANGE, BRLPACKET_IGNOREKEYSET and BRLPACKET_UNIGNOREKEYSET (see brlapi_ignoreKeyRange(), brlapi_unignoreKeyRange, brlapi_ignoreKeySet(), and brlapi_unignoreKeySet())

If the client doesn't want every key press to be signaled to it, but some of them to be given to brltty for normal processing, it can send BRLPACKET_IGNOREKEYRANGE (resp. BRLPACKET_IGNOREKEYSET) packets to tell ranges (resp. sets) of key codes which shouldn't be sent to it, but given to brltty, and BRLPACKET_UNIGNOREKEYRANGE (resp. BRLPACKET_UNIGNOREKEYSET) packets to tell ranges (resp. sets) of key codes which should be sent to it, and not given to brltty. The server keeps a dynamic list of ranges, so that arbitrary sequences of such packets can be sent. For ranges, Data are 2 integers: the lower and the upper boundaries; lower and upper must be equal to tell one key, for instance. For Sets, Data simply consists of integers, one per key in the set.

BRLPACKET_WRITE (see brlapi_write())

To display text on the braille terminal and set the position of the cursor, the client can send a BRLPACKET_WRITE packet. The packet begins with an integer holding flags (see BRLAPI_WF_*). These flags indicate which data will then be available, in the following order (corresponding to flag weight):

A BRLPACKET_WRITE packet without any flag (and hence no data) means a "void" WRITE: the server clears the output buffer for this connection.

BRLPACKET_GETRAW (see brlapi_getRaw())

To enter raw mode, the client must send a BRLPACKET_GETRAW packet, which is acknowledged. Once in raw mode, no other packet than BRLPACKET_LEAVERAW or BRLPACKET_PACKET will be accepted. The data must hold the special value BRLRAW_MAGIC: 0xdeadbeef, to avoid erroneous raw mode activating.

BRLPACKET_LEAVERAW (see brlapi_leaveRaw())

To leave raw mode, the client must send a BRLPACKET_LEAVERAW packet, which is acknowledged.

BRLPACKET_PACKET (see brlapi_sendRaw() and brlapi_recvRaw())

While in raw mode, only BRLPACKET_PACKET packets can be exchanged between the client and the server: to send a packet to the braille terminal, the client merely sends a BRLPACKET_PACKET packet, its data being the packet to send to the terminal. Whenever its receives a packet from the terminal, the server does exactly the same, so that packet exchanges between the terminal and the server are exactly reproduced between the server and the client.

Packets' content depends on the braille driver, so that the client should check for its id or name thanks to a BRLPACKET_GETDRIVERID packet or a BRLPACKET_GETDRIVERNAME packet, prior to sending any BRLPACKET_GETRAW packet.


Next Previous Contents