Bugzilla – Bug 9152
SqueezeNetwork keep track of SqueezeCenter IP addresses...
Last modified: 2013-10-11 13:43:52 UTC
I'd like to see a (I think) fairly simple feature implemented in SqueezeNetwork and SqueezeCenter. If a user leaves port 9000/3483 open to their SC server at home, SqueezeNetwork ought to be able to keep track of thta IP address and serve it as a connection option to a remote player. Here's how I see it working... 1. SqueezeCenter sends regular (hourly?) updates to SqueezeNetwork to tell SN that its up and running. 2. SqueezeNetwork keeps track of which SC servers are still up, and their "outside" IP address. For each client that is up, it attempts to connect to the client on 9000/3483 to verify that remote connectivity is allowed. 3. If access is allowed, the SqueezeNetwork user is presented (via IP3K menu/Web UI) the option to connect to that server as a Music Source. The user would see the standard "Connect to SqueezeCenter" when the SqueezeCenter server is local on the ne twork... but when its remote, they would see "Connect to Home SqueezeCenter" (wording TBD) which would redirect their client to the SC service running at home. Additionally the Web UI for SN would have a link to that same SqueezeCenter server, so that the user can control various things. There might even be a clever way to tell SC that "any remote client" gets Bitrate limited to XXX rate. (I know this is done on a per client basis now.... might be nice to have an options for all remote clients)
Isn't this the same as the bug where we run discovery while connected to SN and populate the Music Source with all the servers on the LAN? I don't think the amount of people who run SC, forward ports, and are also connected to SN is very large.
You've invented a poor man's dynamic DNS. :) Seriously, though, what end-user feature are you trying to enable?
I'm simply trying to bridge the gap between SC and SN... I know its not a common use-case yet, but it may become one. Imagine selling SB's to home-squeezebox-users for their office -- but making it easy/automatic for them to be able to stream music from their home collection. Its possible without this interface, but you have to get your home IP address (which changes frequently), then manually enter it. This would automate that .. yes ... a poor mans dyndns... but since we dont support entering hostnames with the IP3K interface, this saves a step.
The way to make it easy for SN-only users to stream their home collection is the UPnP feature I am going to add soon. :)
Got it, it's a bit like the problem of getting through firewalls that video conferencing has. (Logitech does this with their videocam software, plus proxies videophone conversations when the firewalls fail, a substantial bandwidth cost.) The good news is that SC can connect to SN easily, the trick is solving the firewall problem. We can probably get some help here, but it won't be simple.
Andy, the UPnP stuff won't let you listen to your stuff at home from work, right?
There's no need to make SC actually get around the firewall... just make it clear in the documentation that the user needs to open their firewall themselves.
(Ps, I'm a HUGE supporter of the UPnP idea... but this seems like an interim step that enables a slightly different use case).
OK, yeah I guess I can see the use case here. Not needing to find a tricky way to listen to my home music while at work anymore, I wasn't thinking about that. ;)
If the user already has a domain name with working DNS (dynamic or otherwise), then SN wouldn't need to keep track of IP addresses itself. The user could just enter a list of desired SC instances (by fqdn) in his SN profile. When a switch is requested, SN can do a DNS lookup and send back the IP. Or am I missing something?
Though that works, its not nearly as elegant... that requires the user to have a DynDNS type client on their system and depends on another service. By just having SC send occasional updates to SN (which we can easily control), that entire need is gone.
Will look at this to schedule for a future release.
Andy: is this issue still valid? Should we close or re-target the bug
Still valid yes, it's a future enhancement.
I'd love to see this implemented for 7.4 still... it would provide a nice bridge back for the IP3K players to get to their SC after they've been pulled to SN. Too difficult to implement by then?
wow, i can't believe i haven't seen this bug til now! i talked about this years ago in the forums... matt is right, its ELEGANT to have slim stuff act as ddns. i think both the server and the clients should be able to do this. in various forum threads, i talked about setting up a community social networking site, like this: MrSinatra.squeezebox.net where all the forum names (or whatever) could establish a profile where all your servers and clients meet, and make all your music available to yourself, as well as published for your friends to see, (and play?) you could also publish aggregate stats about what options users are using and how they have them set. very helpful info for developers! upnp should be part of this of course, but this deserves to exist on its own as well.
You're really thinking of suggesting that users open ports 9000/3483? So SC will be hardened against attack as well?
I'm suggesting that for users who wish to do this, it would help quite a bit. There are other issues to consider now that Squeezeplay is involved -- and this ticket needs some rethinking, but its still generally valid I believe.
Without getting to techical about how it should work I feel as a user that if you are connected to MYSB.com on a player at a location without a local SB server the MYSB.com should say: "Hey you have a SB server running at IP: xxx.xxx.xxx.xxx on the internet. Do you want to connect to it?". If you click yes or connect then it would try to connect. If it can't (if you haven't opened the ports at home) it would fail and say couldn't connect etc. It would still be the users' responsibility to open the relevant ports on their access points if they want to do this. With the different apps (flickr, facebook) that now work through mysb.com surely the mysb.com is already being polled regularly by the SB server, so it should know that a server(s) with ip(s) xxx.xxx.xxx.xxx is associated with a certain mysb.com account.
There might be another use case: a "unified" web UI for mysb.com and LMS. Pull down mysb.com's web UI and let it talk to your local LMS (if you happen to connect from your home). In order to enable this feature mysb.com would need to know your server's address, as we can't implement server discovery in the browser using UDP.