1 person found this helpful
maxPeerConnections only affects 1:1 (NetStream.DIRECT_CONNECTIONS) P2P, not groups.
an FMS 4 can join a NetGroup as a client. i'm not an expert on FMS server-side programming, so i might be mistaken about this, but: in FMS 4 you can't subscribe to a multicast NetStream; you can only publish. if you're the multicast publisher, you can set the multicastPushNeighborLimit to higher than the default (which is 4), which will increase the fan-out from your high-bandwidth peer (the FMS as P2P multicast publisher).
there is no way to modify the group topology parameters to increase the number of neighbors the server will try to have/keep. however, if the server is in a favorable network position, it will end up being a favored neighbor for other peers, so it may through natural operation end up with more neighbors than a typical peer. but it won't have connections to *every* peer in a group larger than about 30 no matter what, and you wouldn't want that anyway, since lots of stuff about groups is designed around the assumption that peers have O(log n) neighbors.
Thank you very much. 30 seems to be a secret number, now i know it !
So the answer for "Will the server peer transport the stream data to its neghtbors?" is YES, right?
yes, the server peer is like any other peer in a group (it's all the same code under the hood). however, if the server isn't the publisher of the multicast stream, then it'll only be in "push" mode for the default setting of multicastPushNeighborLimit, which is 4. all of its other peers will be able to request ("pull") the data from the server if they don't get it in a timely fashion from other peers, but you don't want your multicast stream to be operating heavily in pull mode anyway, since that'll perform poorly for everybody. persistent "pull" mode means there isn't enough upload capacity in the mesh to support "push", so a large proportion of peers' upload bandwidth must already be at or near saturation.
in general a member of a group will target having approximately log2(n) + 13 peers, and because the log part of the topology is reflexive, the number of peers will usually be around 2*log2(n) + 13. some of the 13 are "low latency" neighbors (measured by round-trip time). the group will usually be fully meshed when n < ceil(2*log2(n) + 13). that holds up to n=23.
a large number of other peers may find the server to be a low latency neighbor and will prefer to keep it. that can drive the number of neighbors that the server has up dramatically. a member will go into "overload" mode if it has more than about 2.5x the desired number of neighbors, where it'll ask some neighbors to disconnect, and at about 3x desired, a member will start abruptly dropping peers that aren't in the desired topology until it leaves overload mode.
Thank you very much for so many details, they are very helpful.