1

I've implemented the sample code given in this thread. It works a treat as promised. Unfortunately, it will only report back the direct responses to the M-SEARCH request, but nothing else. I'm looking for a way to just listen to the SSDP broadcasts, in order to capture other application's search or notify broadcasts.

I've tried all sorts of configurations with TIdUDPServer, but none was successful. I'm getting to the point where I consider that it might not be possible.

I'm running Win 8.1 with Network Discovery enabled and a MediaServer on another computer on the same network. Firewall on or off doesn't make any difference. Using Window's API for UPnP works as expected and applications using UPnP are detecting the MediaServer and other UPnP devices properly.

Does Window's built-in UPnP service capture those broadcasts on 239:255:255:250:1900 and doesn't pass them on? How can I just listen to those broadcasts?

Community
  • 1
  • 1
Carsten
  • 45
  • 8
  • 1
    SSDP is not broadcast, it's UDP multicast. This means your server needs to join the multicast group before the messages will be delivered (M-SEARCH replies are not multicast so they work). I didn't write this as an answer since I don't know TldUDPServer. – Jussi Kukkonen Aug 24 '16 at 11:37
  • 1
    I think you need to use `TIdIPMCastClient` – Johan Aug 24 '16 at 16:08
  • 1
    Thanks jiu. See the answer below. I guess, I cannot listen to the broadcasts and send my own discovery ssdp with the same instance of the server class, right? This will have to be split into two instances, one for the listener, one for the discovery requests and their answers, right? – Carsten Aug 24 '16 at 17:33

1 Answers1

2

jku pointed me in the right direction. The TIdUDPServer class provides a AddMulticastMembership method, which does the trick. Thanks jku!

Below the code that works:

var
  server : TIdUDPServer;

...

with server do
  Active := false;
  BroadcastEnabled := true;
  DefaultPort := 1900;
  Binding.IP := GStack.LocalAddress;
  Binding.AddMulticastMembership('239.255.255.250');
  active := true;
end;

I was messing about with all sorts of configurations and tests until I noticed that my firewall has blacklisted something. Still need to figure out what it was, but turning the FW off for the tests certainly helped. Resetting my router, too. Apart from the localhost stuff I hadn't seen anything and after the router reset all UPnP devices on the network could be seen, again. Wired. More stuff I need to understand ....

Thanks again and regards

Carsten

Carsten
  • 45
  • 8
  • As Johan stated in another comment, you should be using `TIdIPMCastClient` instead of `TIdUDPServer`. `TIdIPMCastClient` is a UDP multicast client, and calls `AddMulticastMembership()` internally for you. Simply set the `TIdIPMCastClient.MulticastGroup` property to the multicast group you want to join. – Remy Lebeau Aug 24 '16 at 21:08
  • I'm now using the IPMCast Client to listen for broadcasts and it works fine for Win32. Unfortunately, it won't receive anything under IOS and Android. I've read in another thread that GStack.LocalAddresses is not implemented for Android and that it is on the todo list. Is this the case for the IPMCast Client, too? – Carsten Jan 15 '17 at 17:24
  • From a coding perspective, the IPMCast components are implemented on all platforms. But from a logistics perspective, Android (not sure about iOS) has extra requirements that Indy does not account for: http://stackoverflow.com/questions/3179710/. Specifically, a call to Android's [`WifiManager.createMulticastLock()`](https://developer.android.com/reference/android/net/wifi/WifiManager.html#createMulticastLock(java.lang.String)) is required for Android's socket stack to not discard multicast packets. You will have to call that manually in your code using Delphi's JNI Bridge framework. – Remy Lebeau Jan 15 '17 at 19:22
  • Thanks Remy! Never worked with the JNI. I think I'll park that one for the time being and crack on with other stuff ... – Carsten Jan 20 '17 at 17:11
  • Wow, everywhere I look, even advanced and well-known developers are putting such a project on the side. I indeed have the issue where android is returning `127.0.0.1` as its device IP, which obviously would never allow such a thing to work. And, the fact that Apple requires IPv6... what seemed like a simple idea became a monster undertaking. – Jerry Dodge Oct 07 '17 at 00:06
  • 1
    @JerryDodge I've put things aside for iOS for the moment, because of the problem described in the other question. I'm having trouble overall making it work the way I want (even on Windows). Either that, or I'm misunderstanding how it should work (XY thing). If you're doing something similar, perhaps we could collaborate? – Dave Nottage Oct 08 '17 at 03:00
  • @JerryDodge Here's the link regarding my woes on Windows: https://forums.embarcadero.com/thread.jspa?threadID=252980 – Dave Nottage Oct 08 '17 at 03:33
  • 1
    @DaveNottage Thank you, I'm currently focused on other parts of our app of higher priority, and we've bumped server discovery to basically our lowest priority for the moment. We potentially have a different solution we're considering in place of this, so I'm going to hold off of this part. – Jerry Dodge Oct 09 '17 at 13:59