maximum number of mesh memberships per applications
howdy
is there a limit on the number of meshes an application can join? is it only limited to the max number of available sockets on the platform or is there a hardcoded limitation in msp2p? does joning a mesh necesseraly mean utilizing at least one new socket?also in case of an application joining many meshes is the p2p api capabale logicaly reusing open sockets between two peers that are both members of the same two meshes? or for each logical member connection to a mesh a new socket is used even that the two machines are already "neighbours" on a different mesh...?
thanks!
[616 byte] By [
semedao] at [2008-2-14]
Hello,
It sounds like you are designing a p2p application - I'm glad that you're considering Microsoft's p2p APIs, and I hope we can resolve any questions you might have about the framework.
Depending on which one of our technologies you're using, the word mesh can have different meanings. For example, in PNRP the entire cloud can be considered a mesh, and it's unlikely that an application design would require using more than one. In Grouping/Graphing, each group/graph is a mesh, and there's no limitation on how many you can create. In PeerChannel, yet another type of mesh is used. So it's impossible to discuss a unified p2p mesh, because such a thing doesn't exist.
We can discuss the network requirements of a specific mesh implementation, but it's more important to understand which type of mesh is best suited to a particular application design, and how to best leverage it.
As far as socket usage, our protocols ave very conservative in this respect - in the case of PNRP and Grouping, these run in a service, utilizing a single socket for each protocol. When designing a p2p app using our infrastructure, there should really be no concern about running out of sockets. If you have questions about designing such an app, feel free to ask us for advice and recommendations.
Thanks,
Vladimir
thank you for your answer
so let me clear my needs , secanrious and let me understand 100% that I'm right..
what happen about:
number of open sockets (listening , or established) , memory usage , CPU , and other performance issues when we want for wxample to be part of more than 1000 different meshes that openand close many times (and also can have mesh password) in:
- PeerChannel with CustomResolver
- PeerChannel with PNRP
- PeerChannel with CustomResolver and PNRP... (it's other question if I can make some better custom resolving that try first using PNRP and if faild will fall down to CustomResolver - it's to reduce server side work , and because PNRP is not working in all cases)
- direct calls to PNRP
- Grouping/Graphing that you wrote above - what is the difference between using this to PNRP ? , maybe I understand wrong , that Grouping/Graphing is one thing and the way we resolve the peer addreses inside it is using PNRP or (in PeerChannel) CustomResolver ? , let me understand better this issue
thanks again
There is some critical data missing from your scenarios -- how many peers are expected to be in each mesh? Also, I am quite confused as in point 4 you seem to imply that PNRP can join a peer to a mesh without the use of some other component. PNRP can only resolve peernames to addresses. It does not give you a connection you can use to communicate with a particular peer.
I can tell you that connecting and disconnecting to thousands of meshes is going to bring your machine to its knees.
Let's assume you will connect to 4 peers (a reasonable average for a P2P app) in each of 1000 meshes = 4000 open connections.
Further more you will be sending data to these peers, otherwise there is no point in connecting to them.
So, a single peer can send up to 30 kilobytes a second before it would exceed 1 Gigabit ethernet's bandwidth.
PNRP and Grouping authentication involves exchanging certificates. Technically certificates do not have any maximum length but let's assume they're 32KB on average. Since it is quite likely that you are connected to at least 1000 different peers (otherwise why are you using 1000 different meshes?) an application designed this way would easily saturate a GigE connection with the authentication traffic alone unless you could guarantee that peers would only be brought online in a throttled manner.
To answer your question about PeerChannel/Grouping/Graphing and how they are different from PNRP. PNRP is the Peer Name Resolution Protocol. It allows you to resolve a peername to an IPv6 address in a secure or insecure manner (if you so choose). PeerChannel, Grouping and Graphing all connect to peers and exchange data between them. PeerChannel and Graphing can use PNRP to get addresses of peers in order to connect to them but are not required to use it. Grouping uses PNRP and you cannot configure it to use anything else.
Can you please explain your application's purpose to help us better understand the requirement of connecting to thousands of meshes simultaneously?
Thanks,
Eliot
I want to use it in some different way...
to "listen" on many meshes only my peer is participate, and when some other peer register to particular mesh , stop listen on all others
I already tried to open many meshes and the CPU was 100%...for a long time , so I understand that I can't use it in this way.
My question was if the number of socket , memory allocation and other resources become high even in the case of only one (my own) peer in the mesh without other peers
Thank you anyway
Your application's design is interesting. If your application's goal is to advertise thousands of different services (which is essentially what listening on thousands of different meshes does) but only allow one service to be utilized at any one time (which is what you are doing by allowing only a single mesh to be active at any one time) then more efficient solutions are possible.
For example, using PNRP v2.0 you could publish info describing the available services on the peer as part of the extended payload. You could then listen on a single mesh and extend your application's protocol to allow a peer to indicate which service he wishes to utilize. A peer who resolves your peername could check the PNRP extended payload and make a decision about which service she wants to utilize. Then she can connect to the mesh on which you are listening and inform you of the service she wishes to use. Once the mesh is in use you can update your PNRP registration to indicate that the mesh is in use and is only accepting connections for a particular service. Well behaved peers who want to use a different service can be expected to wait to connect to the mesh or stop a connection attempt when informed that the mesh isn't offering the service of interest (malicious peers are another matter entirely but they were just as much of a threat under the previous application design).
Does that sound like a workable app design? There are certainly other possibilities.
-Eliot
Thanks
You right that I want to publish N number of services and to service only one at time.
But it's little different:
Peer X publish 1000 different services, peer Y publish also 1000 different services.
Some of the services are the same on both peers.
Peer Z want to user some service, lets call it "service number 7"
Service number 7 can be served with peer X, Y, both, or sometimes no one...
Peer Z don't know what peer publish this service,
So, in my first design he only needs to register to the mesh of "service number 7" and then resolve the peers that can serve him. (Or if he is offline, so there is no one...)
But how can peer Z know that peer X publish "service number 7" without peer X is in this mesh?
Can I use PNRP no for resolve mesh, but to resolve service inside some peer extended payload?
And if yes, how it's happen?
yes , I can create some global application mesh that all peers inside it , but in this case , peer Z will send request to all mesh (which can be large number of peers) and ask "who publish "service number 7"".... it's sound like bad design that will cause a lot of traffic.
about PNRP V2 , I'm afraid of connectivity problems with peer behind some type of NAT , Firewall , XP os etc (I made some tests , and I understand that I cannot guarantee that it will work 100% in the real world when most of users cannot configure the NAT etc)
So, I am open to any ideas
Thanks
Hi,
PNRPv2 does work on XP. You need to download the KB920342 which will make XP and Vista compatible.
To solve your problem you might consider following solution.
Use the extended payload or the comment field to add some extra information which peer Z can use to decide whether it should contact peer x or y. When peer z resolves for a particular service (i.e. service #7), it can ask for multiple resolve results. If peer x and y both are available, peer z will resolve that service to both peer x and y and then it can decide whom to contact.
Please let me know if you need some more information.
Thanks,
Pritam
Hi , I didn't understand couple of things in your answer:
Where we put the extended payload ?
I understand that I put in Peers X & Y , and peer Z use some resolving to get the peers that offer those services
this resolver cannot get as input any peer name or identity of X & Y
I mean:
Peer Z will make Resolve("Service #7") that will return list of.... {Peer X , Peer Y...}
let me know if I understand correctly
and then 
, How to use it ?
I didn't found any code example (both sides , of peers X & Y , and Peer Z to resolve them)
the example that I saw show how to register peer name , and how to resolve by NAME , not by extended payload info.
Thanks
The extended payload can be added as a part of the registration payload. While registering a peer name in PNRP, you can attach an opaque byte buffer which can contain any application specific data. The same data can be retrived in the resolve process. For more information please check the following link.
http://msdn2.microsoft.com/en-us/library/aa371633.aspx
Here is a sample code on how to use extended payload.
PEER_PNRP_REGISTRATION_INFO RegInfo = {0}; // Registration info data str.
RegInfo.payload.pbData = (PBYTE) "Here is the extented payload"; // Set that to a byte buffer
RegInfo.payload.cbData = strlen("Here is the extented payload") + 1; // size of the byte buffer
RegInfo.cAddresses = // Specify number of addresses
RegInfo.pwzCloudName = // Cloud name
RegInfo.ppAddresses = // address list
hr = PeerPnrpRegister(L"0.try", &RegInfo, &hRegistration); // Now register the name.
Please let me know if you need more information.
Thanks,
Pritam
but how can I resolve the peers that shared the same payload ?
the Resolve method need peer name - it's mean that I need to know WHO have some payload...
I need the oposite , my peer neet to resolve all peers that have some payload... without knowing what peer have it !
something like Resolve("Service #7") - return array of peers that offer this service
and not Resolve("Peer X")
also , if there is something like this , can it resolve specific payload even if it's only part of all payload ?
I mean in the example that you gave:
RegInfo.payload.pbData = (PBYTE) "service #7,service #1953,service #3438276...."; // Set that to a byte buffer
thanks
You resolve the Peername not the payload. Payload is completely opaque to PNRP.
You will get back the same payload while resolving a Peername.
Thanks,
Pritam
so it's cannot help me , because I don't know the peer name that will offer the service
thanks
You can register well defined peername (e.g. 0.service<service number>") from the Peer who wants to host that specific service.
Now Peer Z knows that if he wants to use Service 7 the Peer name will be 0.service7. Similary Peer A wants to use service 20 then he will resolve 0.service20. If Service 20 exists in the cloud, the resolve result for Peer A will have that information. If Service 20 does not exisits, the resolve result for Peer A will be NULL.
Hope it helps!
Thanks,
Pritam
I can't use it because one peer can serve many services
and register many peer names will have resources issues
also many peers can serve the same service.. 
thanks
