共用方式為

How many channels can a mesh handle?

  • 發行項

It is often asked how many different contracts can a mesh handle. How should one go about deciding howmany channels one can create in an application using the same mesh name. Brief answer is: there is no limit. It depends on the application design and traffic characteristics.

PeerChannel allows creating multiple channels on the same mesh. This is useful when you have multiple contract types that you wish to use for mesh communication. A typical example is a multi media session : one can envision a multimedia application based on peerchannel that uses separate channels for sending audio, slides, video etc,... In this case, different calls to CreateChannel will pass different uris that all reference the same hostname. When the same hostname is used by multiple channel factories, they all use the same PeerNode instance as their transport. This causes the messages sent over different channels to be multiplexed at the peernode layer.

Following factors can influence the design factoring:

Security aspects of different channels. Its easy to decide if all of them have the same requirements. Otherwise, you have to consider factoring the contracts based on this need. Not all channels may need to be secured.

One of the main factors influencing the design is the relative bandwidth requirements of various channels. If there is a channel that needs bigger message size and exchanges messages more frequently than others, then you probably dont want to penalize the quy who is only interested in a small chunk of messages by sending him everything and asking him to forward everything. Remember that in a mesh, everyone receives every message and forwards them on unless restricted by hopcount.

Number of such contracts. It is not a good idea at the same time to make every contract a different mesh. This will bloat up the process with lot of peernodes each trying to build their connections, eating up resources for no good reason.

Consider the overhead of having a peernode:

A peernode consists of the following key parts:

A) PeerNode itself : holds most of the configuration. acts as a container of other key pieces of peer node like, flooder, maintainer, service endpoint etc,... Has no processing overhead by itself - Acts as the public face of the node by turning key events into Offline and Online events.

B) Flooder: this is the part that is responsible for forwarding and delivering messages. A duplicate message is dropped by the Flooder. It also has to maintain certain amount of state about each incoming message, to avoid duplicates and replay attacks. It keeps a cache of message id for each message. This cache is cycle - a message id lives for atmost 5 minutes. A messageId is 16byes (unsecured) or 256bytes in case of authenticated messages. If you are receiving messages at the rate of 500 unsecure messages per sec, then your cache contains rougly 2MB of working size per node. On the other hand, if you are receiving 200 authenticated messages per second, your cache can grow to as much as 15MB.

C) Maintenance: PeerNode has a periodic maintenance component to it. Every minute (or every 32 messages it received), it sends back an ack to its neighbors that contains some key stats : how many messages are exchanged. howmany are useful (non-duplicates, untampered). Every 5 minutes or so (often if you dont have enough connections),the maintainer wakes up and checks the health of neighbor connections - if it has more connections than ideal, it prunes off the less useful of them. If you are less than ideal, it acquires more connections.

D) Service endpoint: This is the component responsible for keeping connections with other peers in the mesh. Main state of this component is the tcp listener and peer proxy connections.

E) Resolver service. Mesh factoring is also influenced by the resolver being used. if you are using PNRP, remember that for each mesh you create, a separate PNRP registration (in each cloud) is made on your behalf. Each registered name probably involves one or more network roundtrips as part of its maintenance. If you are using the custom resolver, your traffic and resource overhead is multiplied by the number of meshes you create. as many registrations, resolves, refresh etc,...

Hope this information is useful when factoring the contracts into service endpoints.

Comments