1 person found this helpful
there is no setting to limit how much bandwidth a peer will use. however, for P2P multicast to actually work, each member (on average) MUST be able to upload 1x the stream bandwidth so that each member can receive the stream from its peers. if there is enough capacity in the P2P mesh, then the sharing will be reasonably fair. if there isn't enough capacity in the mesh, then the stream quality will suffer (and probably be unusable) AND most peers will saturate their upload bandwidth.
if you set the multicastPushNeighborLimit to 0, then the peers will operate in a pure "pull" mode. that will probably not share as fairly as if you let the mesh operate in "push" mode. the default push limit of 4 should result in reasonably fair sharing.
when there is enough average capacity in the mesh, then peers with plenty of capacity will do a little more to take up the slack of peers who don't have quite enough capacity.
remember the basic principle of P2P networks: in order to receive something, it has to be sent by someone, and the only someones are the other peers.
Thanks Michael ,
When I set multicastPushNeighborLimit = 1, Then I got different result. So I am confusing how can use I multicastPushNeighborLimit this property in my application to restrict number of neighbor connected to me. Can u please ellaborate this property multicastPushNeighborLimit .
Please also post suitable links for P2P use.
1 person found this helpful
you can't limit the number of neighbors connected to any particular member of a group. the group topology is automatic.
the multicastPushNeighborLimit sets the maximum number of copies of any one slice of a multicast stream that a member will send to its peers. this property is mostly intended for use in situations where you know that specific peers have extra upload capacity (perhaps ones you've deployed youself) where you can increase the number, or for when you know specific peers have less upload capacity, where you might decrease the number. changing this (or any of the multicast paramters) can have undesired consequences if you make the group lopsided or unable to keep up with distributing the stream.
for more information about what's really happening in groups and P2P multicast, please watch Matthew Kaufman's session from MAX 2009:
the push neighbor limit will hopefully make more sense after watching that video.
I found one more issue with P2P. There is a delay of 4-5 second in live streaming.
Can u have any solution how to remove this delay?
Can these properties help if yes than how can I use these properties to remove delay.
the multicast system will always have a delay. it is designed for fair and efficient distribution in a P2P mesh with reasonable reliability and with reasonable latency.
the main parameter that controls the delay also controls the reliability. the maximum delay will be the multicastWindowDuration. however, making the window duration shorter can also decrease the reliability of the stream, paricularly as peers join or leave or at the beginning of a new stream. decreasing the window duration may also require adjusting some of the other parameters, such a the multicastAvailabilityUpdatePeriod and multicastFetchPeriod. at this time we don't have guidance on how to tune those parameters.