"What is GNFSD?"
GNFSD (the GNFS Daemon) is a small addition to the GNFS package
that converts the GNFS program (normally run interactively from the
command line) into a standalone daemon. FAFNER knows how to interact
with GNFSD; once you have one running, you can
register it with FAFNER, and the
two will have merry conversations about task allocation, sieving, solution
files, etc. --- hopefully without intervention from you.
Both GNFSD and GNFS
itself are available for FTP.
"Why doesn't FAFNER use GNFS's traditional task
allocation strategies?"
The GNFS task allocation strategy (centralized databases, exact determination
of Q-count within a Q-range, single-point checkin and checkout of tailored
ranges) makes sense for a centralized approach to task range management. It
does not lend itself very well to the widely distributed database approach
used in FAFNER, however. FAFNER uses an alternative, Web-scalable
scheme for GNFS task representation and allocation.
"How does FAFNER store and distribute tasks?"
Every FAFNER server (and FAFNER problem) is characterized by three small
integers: LEVEL, BASE, and WIDTH. These describe the Q ranges that are
handled by the server, and how they can be legitimately decomposed (for
solution or delegation to helpers). BASE is the number base being used --
base-2 addressing, base-10, base-16, base-36, whatever. BASE is best chosen
globally, for the duration of an entire problem. FAFNER will expect that
all clients use the same base, although you could probably get away with
moving from base-16 down to base-8, or something like that.
LEVEL is the number of Q-range powers-of-BASE that the server spans. For
RSA-130, there are appx 10^10 Q values. The largest RSA130 FAFNER server,
assuming base-10, would be a level-10 server, and the largest sieving problem
(the whole enchilada) a level-10 problem. You wouldn't want that server
to talk directly to clients who want to sieve very small ranges of Q;
instead, they'd be referred down the FAFNER hierarchy to a server whose
level is more in line with the request.
When configuring a server, therefore, the administrator chooses the server's
WIDTH --- the number of significant problem digits. This simplifies
the database implementation considerably; a level-L, W-wide FAFNER
server for RSA130 can treat the most significant 10-L digits of the Q ranges
as a server-constant prefix, and the least significant L-W digits as zero.
It only accepts requests from clients (and client re-servers) with level L',
such that (L > L' >= L-W).
Within the W-wide problem space, FAFNER uses simple flatfile database
management to track problems. What this scheme lacks in efficiency, it
makes up for in portability and resiliency. 10^W inodes will be consumed
for a W-wide,base-10 server; disk space for open and assigned problems will be
about 256KB for width-3, and less than 3MB for width-4. Final solutions
are far larger, but the administrator has the option to pass them up
the FAFNER hierarchy, or back to the central RSA130 site, to stay within
FAFNER's local disk quota.
"How do I decide on a parameterization of my
FAFNER subserver?"
Deciding how to configure a new FAFNER server depends on which system
parameter is likely to be the primary machine constraint. There are 3
rules:
- R1. Limit the amount of network traffic you must bear by
- 1. limiting the number of subserver clients, and
- 2. refusing to accept mismatched subserver clients (those
whose level or width differs from your own by more
than 1 or 2).
- R2. Limit the amount of disk space you must contribute by
- 1. limiting your own width; disk space is O(10^W)
- 2. setting the solution quota relatively low, so that
F* solution files will get offloaded regularly
via email .
- 3. not performing local sieving problems, or accepting
only FAFNER subservers as clients (no individuals)
- R3. Limit the amount of CPU traffic you must contribute by
- 1. disallowing autolaunching of local sieving problems, or
- 2. using gnfsd() or rsh()-based solutions to offload sieving
- 3. reducing network traffic and its associated overhead
(see R1, above).
III. Zen questions:
"Why the name 'FAFNER?'"
FAFNER was the dragon who guarded, among other bankable treasures,
the ring of the Niebelungen. Siegfried killed him, and then killed
the irritating dwarf named MIME as well, thereby striking two
early blows against the wasting of network bandwidth.
"Who wrote this mess?"