Feature/aggregatable-locator-publisher

[pelengami]

Hi,

I have added the aggregatable publisher/locator which create the instances of publisher/locator for each available network adapter.

More specifically for the adapters, which supports multicast and if they are Ethernet or Wireless80211 adapter.

Also added tests and added Moq framework to the tests.

I again did nothing for WinRT/WindowsPhoneSL and UWP10
Please see these projects yourself, most likely just need to add links to files

[Yortw]

Thanks again for your hard work here. I'm not sure when I'll have time to fully review and merge though sorry. Also there was some discussion on issue #43 that this wasn't really what people wanted. I have a branch started to try and do the multi-socket thing, but it stalled due to a lack of time and some design issues. I will have to review this in light of those conversations too.

Again, really appreciate the work though. Thanks!

[pelengami]

No problem

I think this is a very useful thing, to be able to create several entities on different adapters, but to manage them as one.

At least that's what I'm doing :)

And if I add the http listener, we'll get some kind of upnp, only without restful control

What you think, may I add the code with the http listener, which will give a description of the devices to other devices in the network for even more convenient use of the library

[Yortw]

In theory both plans give you the ability to host/listen/search on multiple adapters, it's just how it's done/managed that changes.

I'm happy for you to put a listener in your fork, but I don't want it as a PR. I can see the appeal, but I would like to keep the main project purely about the SSDP protocol and not add features outside of that. Especially something as complex as the HTTP server (yes it might seem simple now, but we'll get feature requests etc and over time it will grow... besides many people, like me, are using this with a self hosted web API or other solution and don't need an inbuilt web server).

[pelengami]

Most likely you are right, perhaps it makes sense to not increase functionality (http server) of the library if it's only for the specific protocol

[Yortw]

If you wanted to look after it, you could create a new repo and package that had the HTTP listener in it and used RSSDP as a dependency. Then people who just want RSSDP can use my package, and people who want a full service solution could use yours. Up to you. A good compromise if that's something you're keen on.

[pelengami]

Hi again,
I created a repo with these functions and with the http server
And made dependence of this library
I don't know how I should keep the license, I just indicated your repository in the description
So I think this PR can be closed