I finally got firefly set up on an old 300MHz notebook repurposed as a Debian server. It’s definitely nifty — but then, I’m still pretty awed by the whole package manager thing.
Yeah, debian is really nice that way.
How does iTunes know there’s a Firefly server out there? Obviously, iTunes is not polling every possible IP for servers. There’s more than a modified http server going on here.
Using multicast discovery. Specifically, multicast dns (http://en.wikipedia.org/wiki/Zeroconf) aka zeroconf, rendezvous, bonjour, etc.
It’s a nice enough protocol, but suffers from the fact that multicast seems only haphazardly supported on consumer grade equipment. When it works, though, it works well.
Do I need to pass through any port other than 3689 on my router/firewall if I wanted to access from outside my home network?
Nope, just 3689. Although if you are on a remote network, you won’t see the server show up on the remote network — limitation of multicast, so you’ll need to use a mdns proxy on the remote workstation to “push” the server into your iTunes shared music list. (more details at: http://wiki.fireflymediaserver.org/SSH_Tunnel).
I’d strongly advise against making 3689 public though. I’d recommend using ssh tunneling as described in the document above.
Also — disregarding the SoundBridge and similar dedicated devices that require a daap server — what is the advantage of a Firefly/iTunes combo over my home network over, say, Samba/Winamp?
None, really, just preference in clients is all. Mostly this was just an exercise in reversing the protocol that got out of control. I won’t argue there aren’t better/more efficient/more standards based solutions for media sharing, just that it’s one that convenient for some folks.