| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
easier to use in mixed environments:
- Add three new members to the request structure:
- a filename specification
- a database type specification
- a system byte prder specification
These allow the client to ask the server for a particular type of
database (Berkeley DB hash/btree/recno, GNU GDBM, dbm, ndbm, etc...)
and get back a meaningful error if the server doesn't support it.
The byte order spec is needed if the database type is byte order
sensntive. You don't, for example, want to read an ndbm database
from a big endian machine on a little endian machine (the ndbm code
will explode). The filename spec lets the client handle things like
ndbm which uses two seperate files per database (foo.dir and foo.pag).
The client can ask for each half, one at a time.
- Add a list of database types and byte order values. Each list has
a wildcard 'ANY' entry which lets the client ask for whatever the
server supports. (XFR_ENDIAN_ANY is useful with the Berkeley DB hash
method for instance, since it isn't byte order sensitive.)
- Add two newserver failure codes: XFR_DB_TYPE_MISMATCH and
XFR_DB_ENDIAN_MISMATCH. The server uses these to tell the client
that it doesn't support the requested type/byte order.
These changes were made at the suggestion of Thorsten Kukuk, the
current maintainer of the Linux ypserv distribution. This allows
Linux and FreeBSD NIS servers to use the same ypxfrd protocol and
avoid accidentally exchanging incompatible map files.
|
