Add documentation for AbsoluteMaxBytes

Document AbsoluteMaxBytes channel config relation to gRPC limits.
Also replace orderer Addresses with org OrdererEndpoints in the channel config documentation (recommended since v1.4.2).

Signed-off-by: David Enyeart <[email protected]>

docs/source/create_channel/create_channel_config.md

@@ -58,6 +58,11 @@ You can see the part of `configtx.yaml` that defines Org1 of the test network be
           Endorsement:
               Type: Signature
               Rule: "OR('Org1MSP.peer')"
+
+      # OrdererEndpoints is a list of all orderers this org runs which clients
+      # and peers may to connect to to push transactions and receive blocks respectively.
+      OrdererEndpoints:
+          - "orderer.example.com:7050"
   ```  
 
   - The `Name` field is an informal name used to identify the organization.
@@ -74,6 +79,8 @@ You can see the part of `configtx.yaml` that defines Org1 of the test network be
 
   - The `Policies` section is used to define a set of signature policies that reference the channel member. We will discuss these policies in more detail when we discuss [channel policies](channel_policies.html).
 
+  - The `OrdererEndpoints` indicates the orderer node endpoints that this organization makes available to clients and peers. Service discovery uses this information so that clients can pass the appropriate TLS certificates when connecting to an orderer endpoint.
+
 ## Capabilities
 
 Fabric channels can be joined by orderer and peer nodes that are running different versions of Hyperledger Fabric. Channel capabilities allow organizations that are running different Fabric binaries to participate on the same channel by only enabling certain features. For example, organizations that are running Fabric v1.4 and organizations that are running Fabric v2.x can join the same channel as long as the channel capabilities levels are set to V1_4_X or below. None of the channel members will be able to use the features introduced in Fabric v2.0.
@@ -113,13 +120,11 @@ Each channel configuration includes the orderer nodes in the channel [consenter
         Port: 7050
         ClientTLSCert: ../organizations/ordererOrganizations/example.com/orderers/orderer.example.com/tls/server.crt
         ServerTLSCert: ../organizations/ordererOrganizations/example.com/orderers/orderer.example.com/tls/server.crt
-      Addresses:
-      - orderer.example.com:7050
   ```
 
-  Each ordering node in the list of consenters is identified by their endpoint address and their client and server TLS certificate. If you are deploying a multi-node ordering service, you would need to provide the hostname, port, and the path to the TLS certificates used by each node. You would also need to add the endpoint address of each ordering node to the list of `Addresses`.
+  Each ordering node in the list of consenters is identified by their endpoint address and their client and server TLS certificate. If you are deploying a multi-node ordering service, you would need to provide the hostname, port, and the path to the TLS certificates used by each node.
 
-- You can use the `BatchTimeout` and `BatchSize` fields to tune the latency and throughput of the channel by changing the maximum size of each block and how often a new block is created.
+- You can use the `BatchTimeout` and `BatchSize` fields to tune the latency and throughput of the channel by changing the maximum size of each block and how often a new block is created. The `BatchSize` property includes `MaxMessageCount`, `AbsoluteMaxBytes`, and `PreferredMaxBytes` settings. A block will be cut when any of the `BatchTimeout` or `BatchSize` criteria has been met. For `AbsoluteMaxBytes` it is recommended not to exceed 49 MB, given the default gRPC maximum message size of 100 MB configured on orderer and peer nodes (and allowing for message expansion during communication).
 
 - The `Policies` section creates the policies that govern the channel consenter set. The test network uses the default policies provided by Fabric, which require that a majority of orderer administrators approve the addition or removal of ordering nodes, organizations, or an update to the block cutting parameters.
 

sampleconfig/configtx.yaml

@@ -66,9 +66,9 @@ Organizations:
             - "127.0.0.1:7050"
 
         # AnchorPeers defines the location of peers which can be used for
-        # cross-org gossip communication. 
+        # cross-org gossip communication.
         #
-        # NOTE: this value should only be set when using the deprecated 
+        # NOTE: this value should only be set when using the deprecated
         # `configtxgen --outputAnchorPeersUpdate` command. It is recommended
         # to instead use the channel configuration update process to set the
         # anchor peers for each organization.
@@ -288,11 +288,9 @@ Orderer: &OrdererDefaults
         # the serialized messages in a batch. The maximum block size is this value
         # plus the size of the associated metadata (usually a few KB depending
         # upon the size of the signing identities). Any transaction larger than
-        # this value will be rejected by ordering. If the "kafka" OrdererType is
-        # selected, set 'message.max.bytes' and 'replica.fetch.max.bytes' on
-        # the Kafka brokers to a value that is larger than this one.
-        # Based on networking configuration the value needs to be tuned. With
-        # default 100 MB node grpc msg configuration, 49 MB is the max can be set.
+        # this value will be rejected by ordering.
+        # It is recommended not to exceed 49 MB, given the default grpc max message size of 100 MB
+        # configured on orderer and peer nodes (and allowing for message expansion during communication).
         AbsoluteMaxBytes: 10 MB
 
         # Preferred Max Bytes: The preferred maximum number of bytes allowed
@@ -609,15 +607,15 @@ Profiles:
                               Rule: "OR('SampleOrg.member')"
 
     # SampleAppChannelInsecureSolo defines an application channel configuration
-    # which uses the Solo orderer and contains no MSP definitions. 
+    # which uses the Solo orderer and contains no MSP definitions.
     SampleAppChannelInsecureSolo:
         <<: *ChannelDefaults
         Orderer:
             <<: *OrdererDefaults
-        Application: 
+        Application:
             <<: *ApplicationDefaults
 
-    # SampleAppChannelEtcdRaft defines an application channel configuration 
+    # SampleAppChannelEtcdRaft defines an application channel configuration
     # that uses the etcd/raft-based orderer.
     SampleAppChannelEtcdRaft:
         <<: *ChannelDefaults