Validate Endpoint is online for Peer Cache
When using Peer Cache, if the Peer is no longer online or not available for connect there is a 7.5 min delay to fail to the next system. if the first connection was a validation of the systems online status ("Are you there") the need for this delay would not be needed. the requesting client could attempt to make connection (presumably when it's doing the resource checks for Battery, CPU load, Disk IO and available connections) and if the connection times out (very short reasonable time) it moves to the next peer on the list.
This is much improved in 1706 production release.
Simply make the timeout or retry a configurable item. The retries are killing us because we have power mgmt policies that enforce power or sleep states. This means peers will not be on. We should be able to configure peer cache to override any retry and hit the DP instantly.
Levi Stevens commented
The 1706 What's new article doesn't really elaborate on this. Can you?
It would be ideal when the MP responds back with a list of clients sources it should be based on a weighted approach. For example, desktops should be weighted higher than laptops. If clients haven't requested a policy in the last 30 minutes should be excluded from the list. Clients serving peer content should sent up a state message so the MP also knows not to list clients that have MAXED it's connections. Wired clients should be weighted higher than wireless. It should also provide clients in the order of the highest weight and most recent communication to MP.
Nash Pherson (MVP) commented
This would definitely make Peer Cache be more useful for broad deployment in production. Right now, if a client has 200 peers that had the content, you can end up with several hours of failing over.