HeaderDoc does not currently provide a way to group classes together, so this page serves that purpose. Not all classes are listed here; the full listing generated by HeaderDoc is here. Those pages are incomplete due to limitations in the current version of HeaderDoc; more classes are documented (like ConnectionAcceptor, Doorway and AccountRegistry, listed below) but for now you will have to go to the header files.
The classes that essentially constitute the Volley core are the following. They also make use of the data and network classes (below).
- The basic unit of communication.
- The object that distributes messages.
- Receives messages.
Receiverthat transmits messages over a network connection.
Messages uses a set of data encapsulation classes to keep track of sizes, data types, lists, and so forth. These are the more significant ones.
- Simply holds a data buffer and its length.
- A data item with a tag (or name) and a data type.
- Manages a list of
TaggedDataItems, with the ability to look them up by tag. This is the superclass of
Message; the parameters of a message are
- A table of data items, where each column has a tag and type. This is the mechanism for storing lists and records in a message.
Several networking classes are used to wrap the low-level networking API, with one implementation for sockets and another for Open Transport (for Mac OS 9).
- Manages a listening socket and performs a certain action when a new connection is accepted. This is an abstract class, and it is the superclass of
NetProxy. HeaderDoc doesn't generate a page for this class because it gets confused by nested classes.
- Manages a connected socket (or endpoint, in the case of Open Transport).
These are the essential objects that define the operation of a server.
They are all subclasses of
- Listens on the server's main port and creates a
Visitorfor each new connection. HeaderDoc doesn't generate a page for this class because it gets confused by nested classes.
NetProxythat represents a client connection.
- Manages the user account registry and permissions, and responds to login attempts. HeaderDoc doesn't generate a page for this class because it gets confused by nested classes.
There is really only one essential class on the client side.
- The client-side analog to
Visitor. The two work together to make the network connection more or less transparent to the other
Receivers on either side.