Export (0) Print
Expand All
This topic has not yet been rated - Rate this topic

Troubleshooting Function Discovery Clients

Function Discovery clients:

  • Always use UDP WS-Discovery for device discovery
  • Always initiate HTTP or HTTPS connections for metadata exchange
  • Sometimes use directed discovery
  • Sometimes use a secure channel (HTTPS) for metadata exchange

The following list shows the typical sequence of messages sent and received by Function Discovery clients. Not all messages are mandatory.

  1. The client sends a Probe message to discover devices and services. If the client is using directed discovery then this message is sent over HTTP or HTTPS; otherwise, the message is sent by UDP multicast to port 3702.
  2. The client receives ProbeMatches messages from matching devices or services. Directed discovery messages are sent over HTTP or HTTPS; otherwise, these messages are sent by UDP unicast and originate from port 3702.
  3. If no XAddrs were included in the ProbeMatches message, then the client will send a Resolve message by UDP multicast to port 3702.
  4. If a Resolve message was sent, then the client receives a ResolveMatches message from matching services. This message is sent by UDP unicast from port 3702 to the port where the Resolve message originated.
  5. The client sends a Get message to request metadata from the device or service. This message is sent by HTTP or HTTPS.
  6. The client receives a GetResponse message with the device or service metadata. This message is sent by HTTP or HTTPS.

The following diagnostic procedures should be used (in order) to help identify problems with a Function Discovery client.

Bb648696.wedge(en-us,VS.85).gifTo troubleshoot a Function Discovery client

  1. If directed discovery is used, troubleshoot directed discovery.
  2. Inspect adapter and firewall settings.
  3. Use a generic host and client for UDP WS-Discovery.
  4. Use WSD Debug Client to verify multicast traffic.
  5. Inspect network traces for UDP WS-Discovery.
  6. Use a generic host and client for HTTP metadata exchange.
  7. Use WinHTTP logging to verify Get traffic.
  8. Inspect network traces for HTTP metadata exchange.
  9. If a secure channel is used, troubleshoot HTTPS secure channel communication.

If the source of the problem cannot be identified using the above diagnostic procedures, follow the directions in Enabling WSDAPI Tracing and contact Microsoft support.

Related topics

Getting Started with WSDAPI Troubleshooting

 

 

Community Additions

ADD
Show:
© 2014 Microsoft. All rights reserved.