I've looked at them before, expecting exactly the same thing as you Greg. As far as I can tell, it still needs a central server to store the names. So the point of all that horrible complexity escapes me.
I ended up scrapping everything that I had done with the p2p classes, and wrote a small web service to cache the names. My clients look for the web service in the local Ip address range and connect to it. The actual p2p code that I wrote to do the communication between processes was also scrapped and written as a web service that stores messages and routes when the requesting client asks for information. I'm still experimenting with it, at the moment I've got 4 raspberry pi's, 4x Windows PC and an old linux machine processing messages. *Si hoc legere scis nimium eruditionis habes*. On Mon, Apr 27, 2015 at 10:17 AM, Greg Keogh <g...@mira.net> wrote: > I may be a bit slow this afternoon but what do you have (what sort of >> clients and environment) and what do you want to do (have them chat?)? >> > > I read a few pages of the P2P chapter and I realise that my original > question is a bit wonky. The P2P classes do not provide a means of > communication per se, they seem to be mostly related to registration and > discovery, which is done through a Windows service. Peer apps register > themselves with an ID, a port and a naming convention, then they can > discover each other, but after that the ball is in your court. > > It looks like the P2P classes just help all the peers find each other, > then it's up to you to use the port and ID you find to start communicating > in an appropriate manner, whatever you choose that to be. > > So it doesn't really work the way I naively expected, and may not be > appropriate for my simple needs of everyone broadcasting to everyone else > (a kind of chat I guess!). > > However, I have more reading to go and if I find anything startling I'll > let you know. > > *Greg K* >
