- Updated the orderer's file ledger to use it's underlying
  blockstore ledger impl's iterator APIs.
- Blockstore iterators must be explicitly closed to avoid
  leaking resources, so now orderer/ledger.Iterator must
  also be explicitly closed. Added Close() to the
  orderer/ledger.Iterator interface.

Change-Id: Id838a661a11bf5b64a0cbb57d75a27d69d251269
Signed-off-by: Luis Sanchez <sanchezl@us.ibm.com>

Change-Id: I804e1df4f496b6976f975767ba474dc3f19aee45
Signed-off-by: Jonathan Levi (HACERA) <jonathan@hacera.com>

clean up on these three docs; trivial change
few small improvements to build first network as well
[ci-skip]

Change-Id: Iee7528ad87f1750dde81a9b7a3dcd1b3b2e522d6
Signed-off-by: Nick Gaski <ngaski@us.ibm.com>

Update prereq doc to reference a npm
version that is compatible with Node SDK

Change-Id: Ie5b09abd4f75ae76a80d17f1fcaac64d386c772f
Signed-off-by: David Enyeart <enyeart@us.ibm.com>

Change-Id: I1b229f8c9bc6b18e85ef97a99372816f836ff08e
Signed-off-by: Gari Singh <gari.r.singh@gmail.com>

- update Makefile
- update release notes
- generate changelog

Change-Id: I05b3ddc00f416d34fe5669a8a09cfd1afc97db9a
Signed-off-by: Gari Singh <gari.r.singh@gmail.com>
Signed-off-by: Jonathan Levi (HACERA) <jonathan@hacera.com>

Change-Id: Icf6b92cefdf4761884813c1ccc30d6c6ed82f1bd
Signed-off-by: Christopher Ferris <chrisfer@us.ibm.com>
Signed-off-by: Gari Singh <gari.r.singh@gmail.com>

Create release test suite in test/regression/release folder
to run release tests after each release is created. We run this
for every job and look for the IS_RELEASE condition. If the
condition satisfies, job executes all release tests otherwise will
skip tests.

Will run this job in silent mode and disable gerrit
voting.

Instructions to run this patch:

clone fabric repo
cd test/regression/release
./runReleaseTestSuite.sh

Change-Id: If45bcdeee4f5ecb28df405815718fe6a8ee2b583
Signed-off-by: rameshthoomu <rameshbabu.thoomu@gmail.com>

Add tools image name to the list of docker images and
update curl command to pick the correct fabric-binaries

Change-Id: I5e520f27edc4ce1c64dcb771e9dc5dc04b735843
Signed-off-by: rameshthoomu <rameshbabu.thoomu@gmail.com>

The flow for channel creation works loosely as follows.

1. Look up channel resources by channelID from ChannelHeader
2. If missing, propose a new channel, based on the config update
3. Extract the channel ID from the config update, create a template
config from the consortium definition, and check if the config update
satisfies the channel creation policy.
4. Add the new channel resources to the channels map.

The problem is that between step 1/2 if the channelID is mismatched, the
internal channel construction logic will believe it is building
channelInner, while externally, this channel gets registered as
channelOuter.

Thus, it is possible to replay a channel creation TX by modifying the
outer header.  The new channel will be somewhat broken and all
configuration updates against it will fail.

This CR adds a simple check to verify that the ChannelHeader ChannelID
matches the ConfigUpdate channelID.

Change-Id: I23b088563016e0aa9f30524887c3c3d49b5942fb
Signed-off-by: Jason Yellick <jyellick@us.ibm.com>

We change the way auto-vendoring works such that deps that
are already vendored are not re-vendored inappropriately.  It was
found that nested vendoring could break the previously employed
scheme.

For example, consider a package "foo/bar/baz".  It's conceivable that
a vendor folder may appear anywhere in that hierarchy, e.g.

[ "foo/vendor", "foo/bar/vendor", "foo/bar/baz/vendor"]

and golang would recognize the contents as a legitimate vendor.

This was precisely the situation when we had chaincode in the package

github.com/fabric/hyperledger/examples/chaincode where

github.com/fabric/vendor was in effect.

We now scan the entire package heirarchy to ensure we capture the
potential relationships regardless of where they sit in the tree.

Fixes FAB-4883

Change-Id: I7c6aa5ba0401cecc26bc58f5e6cda6e208109411
Signed-off-by: Greg Haskins <gregory.haskins@gmail.com>

This patch set is for updating the doc page with the correct wording.
Refer to FAB-5195, which was opened to fix the tool itself.

Change-Id: Ia6831a305f1a0ca3582128243a37bf346b8803ca
Signed-off-by: Nao Nishijima <nao.nishijima@hal.hitachi.com>

Changes any reference to Hyperledger Project to
just Hyperledger.  Also fixes / corrects the use
of project in conjunction with Hyperledger
Fabric to make things more clear

Change-Id: I3bb8a1c77a2a47c4a885586fe2108e4be8337244
Signed-off-by: Gari Singh <gari.r.singh@gmail.com>

Java chaincode support was removed for v1.0.0 so
need to make this clear in the docs as well as clarify
that Go is the only fully supported language for
chaincode.  Also added a link to Hyperledger
Composer under supported languages as well

Change-Id: I8bbc9e65f371df9d0835910f89a22bba16568074
Signed-off-by: Gari Singh <gari.r.singh@gmail.com>

Docker Namepace should be Docker Namespace

Change-Id: Id3049bef4b2c0df81a6c4d7970ade27f8b3eb44d
Signed-off-by: Gari Singh <gari.r.singh@gmail.com>

In gossip, when block messages are gossiped among peers the
signature of the ordering service on them is validated.

This causes a message to be validated in several places:

1) When it is received from the ordering service
2) When it is received from a peer via forwarding or pull
3) When it is received from a peer via state tranfer

The problem with (2) is that it is done in an inefficient way:
- When the block is received from the communication layer it is verified
  and then forwarded to the "channel" module that handles it.
- The channel module verifies blocks in 2 cases:
  - If the block is part of a "data update" (gossip pull response) message
    the message is opened and all blocks are verified
  - If the block is a block message itself, it is verified again,
    although... it was verified before passed into the channel module.
    This is redundant.

But the biggest inefficiency is w.r.t the handling in the channel module:
When a block is verified it is then decided if it should be be
propagated to the state transfer layer (the final stop before it is
passed to the committer module). It is decided by asking the in-memory
message store if the block has been already received before, or
if it is too old.

The problem is that this is done *AFTER* the verification and not *BEFORE*
and therefore - since in gossip you may get the same block several times
(from other peers) - we end up verifying the block and then discarding
it anyway.

Empirical performance tests I have conducted show that for blocks
of 100KB, the time spent on verifying a block is between 700 micro-seconds
to 2milliseconds.

When testing a benchmark scenario of 1000 blocks with a single leader
disseminating to 7 non-leader peers, with propagation factor of 4,
a block entry rate (to the leader peer) of bursts of 20 blocks every 100ms,
the gossip network is over committed and starting from block 500 -
most blocks were dropped because the gossip internal buffers were full
(we drop blocks in order for the network not to be "deadlocked").

With this change applied, no block is dropped.

Change-Id: I02ef1a203f469d324509a2fdbd1c8b449a9bcf8f
Signed-off-by: yacovm <yacovm@il.ibm.com>

There are still several places in the docs
which do not properly use Hyperledger Fabric
when referring to Hyperledger Fabric.

While this change covers a lot of files, it
simply changes all reference to
Hyperledger Fabric or provides a minor rewrite
to avoid using the terms at all.

As part of this, also addressed
- FAB-5014
- FAB-5139
- Changed docker to Docker as appropriate
- Other minor cleanups since this included most of the docs

Change-Id: I7818a44b1411abb536a595c537202615bf901199
Signed-off-by: Gari Singh <gari.r.singh@gmail.com>

In gossip whenever a batch of channel-scoped messages
(either leadership, blocks, stateInfo, etc.) is sent to remote peers,
a function goes over all existing alive peers and then selects from
them a subset of peers. This is done in gossipInChan function

In case of leadership messages, the subset is taken from the entire
membership set without an upper bound (we gossip leadership messages
to all peers in the channel), and in case of non-leadership messages
the subset is taken with an upper bound equal to the propogation
fanout (configurable).

Finding peers that are eligible to receive any channel-related data
involves cryptographical computations and is non-negligible
(measured ~ 25ms in a network of 8 peers)

The 2 possibilities (leadership and non-leadership) are calculated even
though each method invocation of gossipInChan receives only 1 type of message.
Therefore, it would be beneficial performance wise to just calculate the
option that is relevant to that method invocation and not calculate
both options each time.

This commit addresses this by calculating the peers to send according to
the type of message in the invocation.

Change-Id: If6940182f83ef046c1d1f7186a71946128591e69
Signed-off-by: yacovm <yacovm@il.ibm.com>

In gossip there are send and receive buffers that are
allocated for each connection.
When the throughput of messages is too high and the send buffer
overflows, the connection to the peer is closed and the peer is removed from the membership.

From performance evaluations I did - I conclude that:
- Increasing the send buffer size would benefit to withstand
  intense bursts of messages, even when the receive buffer stays the same.
- Not closing the connection to the peer (and not removing it from the membership)
  that its corresponding send buffer overflowed helps the throughput by giving the
  runtime an opportunity to recover in spite of an intensive burst.

Change-Id: I7bc84092e366b75b6cbcaee1ea9d5320274dfc1c
Signed-off-by: yacovm <yacovm@il.ibm.com>

Authorization error contains bin data (package) which is useless
for error reporting and would get in the way of SDKs and other
tools's reporting. This CR removes the bin data. Further we don't
want to peek into the data on auth. failure and so will _not_
attempt to read the package to enhance the reported error.

. patch 2 fixed lscc unit test to look for right error string

Change-Id: Ic55eba8d890aa2489488fdbd54d4ccc3a8483fed
Signed-off-by: Srinivasan Muralidharan <muralisr@us.ibm.com>

There are still a couple of coming soon
and WIP docs which show up via search.
Some are no longer needed and some will
be addressed in the future.  For both cases
we should remove them for the release.

Change-Id: I8a890431c48200b16da4383b7781deb6ba49cdeb
Signed-off-by: Gari Singh <gari.r.singh@gmail.com>

While it is possibly implied/required that you
should install libtool from the prereqs section
and/or also clone the fabric, there is really
no need to add this overhead if you simply
want to build chaincode.  We can use the
nopkcs11 build tag to avoid libtool and
we can add go get for getting the shim package

Change-Id: I96936d11dfaa14e2a85d99506deddbcc8fed4c2a
Signed-off-by: Gari Singh <gari.r.singh@gmail.com>