service-discovery

The grand design is the following: There is certain application that gets installed as a Windows Service There may be several of these on the network Each of them exposes some interface to the network (think of it as "remote control" or "configuration" - that kind of thing) Then there is another application that acts as a client for that interface (using same analogies - "remote controller" or "configuration tool") The objective of the latter is to sniff out all instances of the former on the network, display them as a list to the user and allow the user to poke them in different places using

Is there a library for implementing service discovery and publishing via UPnP? (I am trying to find some alternatives to JmDNS that while protocol-wise worked fine for our purposes, was highly unstable as a library, having an unacceptably bad tendency for deadlocking itself.) http://4thline.org/projects/cling/ Open Source DLNA/UPnP stack, libraries, and tools for Java and Android developers You could also try ohNet which includes Java bindings and control point / device stacks under a BSD license. (Disclaimer: I have contributed to this project) 来源： https://stackoverflow.com/questions/3229665

I'm trying to enable service discovery in my client-server application using JmDNS. I fully understand service registry on the server side, with code that resembles this: JmDNS jmdns = JmDNS.create(localhost); jmdns.register(serviceInfo); However, I'm having trouble figuring out how to have my client retrieve the port number and IP address from the registered service and use this data to open a TCP connection. I've searched for examples of how to use JmDNS but to no avail. Can anyone here give me some basic examples? Or if anyone has any links to good resources/tutorials on JmDNS could they

The client connects to the server using GenuineChannels (we are considering switching to DotNetRemoting). What I mean by find is obtain the IP and port number of a server to connect to. It seems like a brute-force approach would be try every IP on the network try the active ports (not even sure if that's possible) but there must be a better way. Consider broadcasting a specific UDP packet. When the server or servers see the broadcasted UDP packet they send a reply. The client can collect the replies from all the servers and start connecting to them or based on an election algorithm. See

Wifi P2P service discovery is not behaving as expected. I am seeing intermittent issues where the DNSSD listeners are not called always and hence I have no clue of nearby devices running the same app. I am using the following two APIs - one to register a service to be discovered by other devices and the other to discover the nearby services running on other devices. Any idea if I am doing anything wrong here or is there some specific sequence of other android API calls that need to be made before I call these APIs to ensure that the listeners are always called whenever there is a new service

Intro: I successfully implemented a WCF Service hosted in a Windows Service a few days ago. The community here at StackOverflow helped me with the WSDL exposure here . I thank you once again. However recently I found out that there is another potential client for this service this time located on the same machine as the service and this lead me to think I should add another endpoint with the namedPipesBinding. Named pipes seem to be the best solution for intra-machine communication as far as I am concerned. Please correct me if this is wrong. Problem: I need to expose another endpoint for the

I want to be able to discover Android devices on my network and possibly retrieve some device information about them. This is very easy with Apple devices since they run Bonjour services. However, I can't seem to find any similar service running on Android. This must work without modifying the Android device, installing some service, or opening some port. It's meant to work with vanilla Android devices in the way that Bonjour helps you find vanilla Apple devices. Even being able to just verify that the device is running Android would be sufficient. Chosen Answer : Although it's not the top