Skip to content

G
go-ipfs
切换分支/标签
  1. 19 5月, 2015 5 次提交
  3. 18 5月, 2015 7 次提交
  5. 17 5月, 2015 7 次提交
  7. 15 5月, 2015 1 次提交
  9. 14 5月, 2015 1 次提交
  11. 13 5月, 2015 2 次提交
  13. 12 5月, 2015 6 次提交
    • Issue #873. Thought I might do a small change first to get my feet wet. · 26ba3e1f
      由 Tim Groeneveld 提交于
    • Merge pull request #1215 from eris-ltd/cors · ad9d84d5 
      Add CORS middleware handler to the API.
      由 Juan Batiz-Benet 提交于
    • Merge pull request #1227 from ipfs/parallelize-handshake · 414ab636 
      net/p2p + secio: parallelize crypto handshake
      由 Juan Batiz-Benet 提交于
    • travis-ci: make test_all_commits · 482a492a 
      After losing jenkins, it's been difficult to test all commits
manually. This commit adds a Makefile target that makes travis do it.
Unfortunately, this is way too slow. It takes longer than the
allotted 10min.

After asking the travis people what to do, someone suggested making
sure that each commit is pushed to github independently. This makes
travis run CI on every single commit in the PR, and gives us nice
status indicators on each one (so we know which ones did not pass).

This approach means that we need to push a branch to the repo for
each commit in the PR-- otherwise travis may cancel its run if it
detects that the branch is no longer there. We could automate this
with a bot that essentially does:

  for each PR:
    git fetch the PR branch
    push a branch per commit: <branch>-<commit>

  for each closed PR:
    delete all branches with pattern <branch>-<commit>
      由 Juan Batiz-Benet 提交于
    • Merge pull request #1221 from ipfs/unrestricted-api-access · 0c8a0975 
      Add option to allow unrestricted API access
      由 Juan Batiz-Benet 提交于
    • net/p2p + secio: parallelize crypto handshake · b84fa2b4 
      We had a very nasty problem: handshakes were serial so incoming
dials would wait for each other to finish handshaking. this was
particularly problematic when handshakes hung-- nodes would not
recover quickly. This led to gateways not bootstrapping peers
fast enough.

The approach taken here is to do what crypto/tls does:
defer the handshake until Read/Write[1]. There are a number of
reasons why this is _the right thing to do_:
- it delays handshaking until it is known to be necessary (doing io)
- it "accepts" before the handshake, getting the handshake out of the
  critical path entirely.
- it defers to the user's parallelization of conn handling. users
  must implement this in some way already so use that, instead of
  picking constants surely to be wrong (how many handshakes to run
  in parallel?)

[0] http://golang.org/src/crypto/tls/conn.go#L886
      由 Juan Batiz-Benet 提交于
  15. 11 5月, 2015 1 次提交
  17. 10 5月, 2015 10 次提交