The Publisher machine is basically a CM machine that users don't have access to. All communication to the publisher service (even if it is running on the same machine) is done via some database tables (exposed in the UI as the Publishing Queue, but obviously this is a simplified view of it).
Basically the publisher service, on startup, starts "listening" to the publish queue, and will start picking up jobs from there whenever they appear. It has all the features you would expect on a system like Tridion - the publisher service will lock the job so that other publishers don't work on it, etc - and then handle the resolving, rendering and transporting of the publishing package.
It really is that simple. You can go into a lot more complex configurations, with certain publishers listening only for jobs from a given publication, for a given target or for a given priority, but if all you want to do is to make sure it's a separate box that handles the publishing load then you just have to:
- Get a license for the publisher machine
- Install it as a normal CM box, connecting to the same database
- Deploy any event systems you may have that are triggered by publishing actions
- Deploy any custom resolvers or custom renderers you may have developed
- Stop IIS
- Stop the Publisher service on the original CM box
You're good to go.
Following up from comments, the Publisher and the Transport service work in tandem. Each publisher service talks to "its own instance" of the Transport service via JNI (there's a lot of reasons why the Transport is built in Java, which made sense back in the day and perhaps not so much today - but why change what works?) and this communication is "machine-local". So, yes, a publisher service needs a transport service to be running on the same machine.
You can also fine tune the number of threads that the publisher and the transport will use for rendering and transporting in the MMC Snap-In. Beware that more threads != better performance. Finding the right balance between # of threads and performance is an art, with a lot of variables that may impact it - database performance, template optimization, network bandwidth between transport & deployer, etc.
On another note, I have learned a lot about the publisher by simply reading the output of
tcmpublisher /debug (stop the windows service first).