On Tue, 2005-09-06 at 21:19 +0200, Johan Lund wrote: > If this is implemented than it will be possible to open that given > port through a firewall on the local host or at any firewalls in > between music browsers. The problem here is that the user experience is terrible in the case where the port is already bound. We'd be basically asking our users to pick a magic number, and sometimes the magic number they pick doesn't work, and they have to try another magic number. Let's look at the cases here: 1) Firewall on local host You mention that it would be possible with a fixed port it would be possible to open that port for the local firewall. But why can't you do that with a dynamic port too? If the policy is that Rhythmbox should be able to share music through the firewall, then the right technical way to implement this in my opinion is to have a system where the user session can request open ports on the firewall. Maybe this could be D-BUS talking to a system daemon, whatever. A fixed port is worse not just in that the user experience is terrible when another app happens to be bound; you could also get apps other than Rhythmbox which are suddenly exposed outside the firewall even though you don't want them to be, just because they happened to pick that magic number! Another solution here is to simply not have a firewall on the laptop. I've never seen it as providing much value; if you don't want applications listening on the network, then fix the apps. 2) Firewall on hosts in between In what situations does this happen? The primary use case for Rendezvous services (or whatever they're called now) is between hosts on the same LAN. There's generally no firewalls between LAN segments. Now, if you want to use the music sharing between say two hosts on the Internet in general, the design has to change significantly. You aren't able to do service discovery since the Rendezvous broadcasts don't cross LAN segments. If you wanted Rhythmbox to be a client here, the minimal approach is to have a UI for entering an IP address and port etc, which clearly sucks. If we wanted to do Internet music sharing, the right way probably is to leverage RaphaÃl Slinckx's work to allow buddies to browse each others' libraries, etc. The point here really is that a static port is only a minimal part of the technical issues involved
Attachment:
signature.asc
Description: This is a digitally signed message part