Re: [Rhythmbox-devel] Music sharing

[Charles Schmidt <cschmidt2 emich edu>]

On Tue, 2005-09-06 at 15:44 -0400, Colin Walters wrote:
> 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.

I can try, but I'm not sure how mDNS behaves with a firewall between
hosts.

> 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!

We could try to bind to the 'standard' daap port (the one iTunes uses)
of 3689 first, and failing that bind to any available port.  Problem is,
that without a D-BUS system like you're talking about the user wouldn't
know which has happened, and if the bind happened on port 3435 or
something, music sharing won't work and the user will complain.  I've
already made this change to my copy, and I'll commit it if people want,
but, like walters says, I dunno that it'll do that much good.

>   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

While it /should/ work, because of latency issues, lack of Rendezvous
support (afaik) and just "why?", I can't say that music sharing between
to random internet hosts will work or should work.

Alternatively, we could have a UI (or perhaps just GConf keys) for
"known music shares" on the internet, which would automatically be
populated to the source list on start up, without any Rendezvous voodoo.
However, like I said, I don't know that this would work.

-charlie