About:

 Jaffer is a Java implementation of Appletalk File Protocol v3.1 using
 TCP Transport. Performance on a Gigabit network exceeds both Samba and
 Netatalk. No, Really. Disable debugging.


Disclaimer:

 This software is not extensively untested. Because OS X's AFP/TCP client
 appears to be full of code that does little or no bounds checking, you
 should not UNDER ANY CIRCUMSTANCES connect to a Jaffer server with a client
 machine that is running important services. This could result in the 'white
 screen of death'. If this happens, it is a bug in Jaffer. Please report it.


Status/News:

 2007 May      25 (v0.07) added zipfs, refactoring for jdk1.5
 2007 May      23 (v0.06) fixed volume mount and copied file timestamps
 2007 May      22 (v0.05) fixed appletalk documentation links
 2003 February 13 (v0.05) added samba-style config. fixed resource forks
 2003 February 10 (v0.04) added support for UAM and AFP2.3 read/write
 2003 February  7 (v0.03) large file fixes, memory and performance work
 2003 February  5 (v0.02) mounting, reading, writing and resource forks

 Check out the SourceForce project page and mailing list.


Quick start:

 This program will act like a native Appletalk file server. You must run it
 as root to use Appletalk's normal port 548. But it's just as happy running
 on any unpriviledged port. To access shadow passwords, the server must be
 run as 'root'.

 Your client must be a Mac OS X 10.2 or newer system.

 Download a recent build and source code.

 Or browse the source in svn.

 Run the server:

   java -jar jaffer.jar -config [config-file]

 or, alternatively, for quick testing:

   java -jar jaffer.jar -server [port] [volume-name] [path-to-export]

 From the OS X Client, mount the new volume:

   mount_afp afp://[user]:[pass]@[host]:[port]/[volume-name] [mount-point]

 The '[user]:[pass]@' part of the url is optional. If omitted, the mount
 will be attempted as a 'Guest' user.


Developers:

 Most of your work will most likely be done in the AFP_Session class
 implementing additional AFP calls. When you do this, please be mindful
 of comments in the code. They are sparse, but very important. When you
 add call implementations, please make sure they are represented in the
 AFP_Constants file and annotated with the page number in the AFP3.1
 reference PDF.

 Most of the implementation is geared towards AFP3.1 which means that some
 of the helper and common methods are not usable for AFP2.3 or earlier
 protocols.


Reference documents:

 Appletalk Protocol Programming Guide
 http://developer.apple.com/documentation/Networking/Conceptual/AFP/Introduction/chapter_1_section_1.html

 Appletalk 3.1 Reference
 http://developer.apple.com/documentation/mac/pdf/Networking/AFP.pdf

 Appletalk 2.1/2.2 Reference and Appletalk over TCP
 http://developer.apple.com/documentation/macos8/pdf/ASAppleTalkFiling2.1_2.2.pdf


Licenses:

 The Java AFP code is covered under the terms of the 'License' file found
 in this directory. Included in the source tree you will also find a copy
 of Stangeberry's Java Rendezvous code. This is covered under the terms of
 the GNU Lesser General Public License. A copy of this license can be found
 in the Java Rendezvous source tree.


Mini-FAQ:


Q. OS X crashed while I was doing XYZ with this thing.


A. OS X appears to have an exceptionally fragile implementation of an AFP3
   client. It should never crash when it receives a badly formed response,
   but this is unfortunately the case. When this happens, it is indicative
   of a bug in Jaffer. Please report it along with the console log from the
   Jaffer server. Obviously you can't do this if the server was also running
   on your OS X machine. So, if you're going to test at this stage, please
   A) run Jaffer on a different server from the client and  B) leave the
   debugging at a very verbose level.



Q. How do I disable debugging?


A. pass the parameter "debug.afp=#" to the server where #=0,1,2
   java -Ddebug.afp=1 -jar jaffer.jar ...
   alternatively, launch Jaffer using the config file and set debugging there.



Q. It's written in Java. How fast could it be?


A. I've done some preliminary benchmarking using Gigabit ethernet and a Linux
   RAID fileserver. Jaffer was able to sustain client reads at a rate of over
   30MB/s with bursts of over 40MB/s. In contrast, using the same setup, Samba
   was only able to sustain 25MB/s and Netatalk about 27MB/s. This is promising
   since real IO optimizations (like use of Java 1.4's NIO) have not been done.
   The test files were over 30GB in size and tests ran for several hours. Yes,
   I do have a background in benchmarking and Java performance tuning.