Make JMM Server discoverable

[jmediamanager]

Reported by werndlymob, Aug 30, 2012

http://msdn.microsoft.com/en-us/library/dd456791.aspx

This will allow JMM desktop and MyAnime3 to find a list of available JMM Servers on the network without having to manually enter the address.

JMM Desktop should also store the list of import folder mappings per JMM Server instance, so that one JMM Desktop can connect to multiple servers.

Have a button on the config screen to search for servers, and a new button to switch servers in bottom toolbar

[bigretromike]

Should be a easy task without wcf. Search for any ip that have http/port 80 open and running and query for /api/version and if the respond if valid then you have your server. So this issue is more of Client issue now if its still needed. @ElementalCrisis what do you think?

[ElementalCrisis]

Yeah, was already thinking about this for the new Desktop UI, I hate the current screen you get when JMM Server is not running. If we can add it into the Server API then all the better.

[bigretromike]

Every thing needed on server side is already there

On October 6, 2016 3:20:02 PM GMT+02:00, ElementalCrisis notifications@github.com wrote:

Yeah, was already thinking about this for the new Desktop UI, I hate the current screen you get when JMM Server is not running. If we can add it into the Server API then all the better.

You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/japanesemediamanager/jmmserver/issues/26#issuecomment-251959097

Sent from my Android device with K-9 Mail. Please excuse my brevity.

[maxpiva]

This is not an easy as it seems, you will not search an entire 255 or 65535 or 16777215 ip in search for the api. To be Discoverable, we need to open an udp port, and do a multicast from the clients. The ip that respond that multicast, are the servers. We could open the same ip:port as nancy for the udp.

On Thu, Oct 6, 2016 at 10:51 AM, BigRetroMike notifications@github.com wrote:

Every thing needed on server side is already there

On October 6, 2016 3:20:02 PM GMT+02:00, ElementalCrisis < notifications@github.com> wrote:

Yeah, was already thinking about this for the new Desktop UI, I hate the current screen you get when JMM Server is not running. If we can add it into the Server API then all the better.

You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/japanesemediamanager/jmmserver/issues/26# issuecomment-251959097

Sent from my Android device with K-9 Mail. Please excuse my brevity.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/japanesemediamanager/jmmserver/issues/26#issuecomment-251967122, or mute the thread https://github.com/notifications/unsubscribe-auth/ABHDbapadw1hiQMyV1j_bn6Eikxt-FY5ks5qxPzUgaJpZM4CYoJ7 .

[bigretromike]

usly people tend to use small netmask /24, so scaning for 255 ips aint big problem. UDP broadcast is also a way - but will we really use it as much ? Wouldn't it be easier to jmmserver just show your local ip ? wouldnt it be safer/faster/easier - and we would have to have ability to disable this when moving to cross-platform service. (also thats will be probably output into console when running so...)

But yes, that is also a way.

[maxpiva]

You need to have a solution that works on all cases, not on the majority of the cases. you could show you jmmserver ip just right. also udp is not a showstopper could be used in mono without problems.

As always stackoverflow has working example, adding this should be trivial...

http://stackoverflow.com/questions/22852781/c-sharp-how-to-do-network-discovery-using-udp-broadcast

On Thu, Oct 6, 2016 at 1:30 PM, BigRetroMike notifications@github.com wrote:

usly people tend to use small netmask /24, so scaning for 255 ips aint big problem. UDP broadcast is also a way - but will we really use it as much ? Wouldn't it be easier to jmmserver just show your local ip ? wouldnt it be safer/faster/easier - and we would have to have ability to disable this when moving to cross-platform service.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/japanesemediamanager/jmmserver/issues/26#issuecomment-252016567, or mute the thread https://github.com/notifications/unsubscribe-auth/ABHDbbmYDX-5ORXnXupioDzss0F0Jk-eks5qxSIxgaJpZM4CYoJ7 .

[bigretromike]

yeah, thats look like a good example - but the main question is, is this old issue is still valid for our need ? Why I ask? Because most people use JMMServer with JMMD and with aditional player (plex, kodi), and the minimum information needed for those is to know what IP is used.

Is one time only JMM Client setup is enought to make JMMServer broadcast all the time discover packet?

Imo, No

But you guys should decide if this is needed and if not close this ;-)

PS. If we realy need one-time-discover than iterating thru netmask /24 is the easiest because its only max 254 hosts to scan and in most cases it even less - as its only one time use only and never need again, no extra setup, no extra checking each time if broadcast should be enabled, no need to reset that setting...

[hidden4003]

Is it necessary for JMM Server to broadcast at all? I was thinking that a client should send broadcast packet when you press button / open popup etc. so it will work similarly to a DHCP server.

[bigretromike]

Then server would listen all time ? It would be same as server broadcast imo. Im for scanning its client scan, shouldnt take long in normal user case /24 (netmask) but if you want any other solution with listening/broadcasting please add disable button so we dont waste resource in cases that done need discovery

On October 9, 2016 9:20:41 PM GMT+02:00, hidden4003 notifications@github.com wrote:

Is it necessary for JMM Server to broadcast at all? I was thinking that a client should send broadcast packet when you press button / open popup etc. so it will work similarly to a DHCP server.

You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/japanesemediamanager/jmmserver/issues/26#issuecomment-252506449

Sent from my Android device with K-9 Mail. Please excuse my brevity.

[maxpiva]

Okey. How generating 254 tcp connections, and wait for response, with timeout is better, than send only one udp packet by the client? (How much time and threads you waste for this)

How much waste resources generates binding one port for listening?

Seems the solution presented is not understand.

1) server binds an udp socket, and listen for connections. When a packet is received, response with a packet with the server version. Nothing more, nothing less.

2) Client wants to discover servers.... Client send one udp packet, but instead on a fixed ip, it send a broadcast, then client wait for receiving packets, for, let say, 2 seconds, any receiving packets in that period will come from the servers ips.

Done, you have your connectable servers, without any kind of IP Class limitation, if your mask is 255.0.0.0 or 255.255.000.000 or 255.255.255.0 it will work.

[bigretromike]

People at home use /24 anyway.

Also binding to one port eat more resource than not doing it ;-)

Also as I state im fine with anyting while having ability to disable that bind.

On October 10, 2016 4:49:10 AM GMT+02:00, Maximo Piva notifications@github.com wrote:

Okey. How generating 254 tcp connections, and wait for response, with timeout is better, than send only one udp packet by the client? (How much time and threads you waste for this)

How much waste resources generates binding one port for listening?

Seems the solution presented is not understand.

1) server binds an udp socket, and listen for connections. When a packet is received, response with a packet with the server version. Nothing more, nothing less.

2) Client wants to discover servers.... Client send one udp packet, but instead on a fixed ip, it send a broadcast, then client wait for receiving packets, for, let say, 2 seconds, any receiving packets in that period will come from the servers ips.

Done, you have your connectable servers, without any kind of IP Class limitation, if your mask is 255.0.0.0 or 255.255.000.000 or 255.255.255.0 it will work.

You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/japanesemediamanager/jmmserver/issues/26#issuecomment-252530636

Sent from my Android device with K-9 Mail. Please excuse my brevity.

[Cazzar]

I know this is a old thread, but how about we use mDNS, IP scanning is not a good thing, especially if you are trying to deal with possibly multiple ports.

May not even be that useful with docker anymore since the port mapping could be arbitrary on the host side.

[revam]

Do we still want this now that we're phasing out the desktop client?

[da3dsoul]

No this is dead

[bigretromike]

would be always nice to be able to "find" server but server lack anything useful right now.

[da3dsoul]

With Desktop being deprecated, it wouldn't make sense, as you couldn't get to the webui unless you know where the server is at

[da3dsoul]

It would more reasonable to implement in Nakamori, Shokofin, etc, but that's not my decision

[revam]

I'm not going to babysit the users of Shokofin so hard that I will tell them where they are running their server. They'll need to know that much. Docker and/or other types of network related isolation methods also make it a lot harder to know. 😔

As for Nakamori — or any other client for that matter — i don't know. 🤷‍♂️

[bigretromike]

It would more reasonable to implement in Nakamori, Shokofin, etc, but that's not my decision

Kodi has this function.

This functionality if ever wanted should be on server not on client. server provides - client consume.