According to the source code, TCP transport method Transport#filter() relies on mafmt's TCP matcher function (mafmt /src/index.js:18) which doesn't match unix sockets: src/index.js:135. So it's impossible to listen unix sockets. And attempts to provide unix path to Transport fails:

import path from 'path'

import Libp2p from 'libp2p'
import Tcp from 'libp2p-tcp'
import Mplex from 'libp2p-mplex'
import PeerId from 'peer-id'
import PeerInfo from 'peer-info'
import Plaintext from 'libp2p/src/insecure/plaintext.js'



const serverPeer = await PeerId.create()
const serverInfo = new PeerInfo(serverPeer)

serverInfo.multiaddrs.add(
  path.join('/unix', path.resolve('unix.sock'))
)

const node = await Libp2p.create({
    peerInfo: serverInfo,
    modules: {
      transport: [Tcp],
      connEncryption: [Plaintext],
      streamMuxer: [Mplex],
    },
})

The code throws ERR_NO_VALID_ADDRESSES. I'm not sure if it the TCP or mafmt package error. I'm not sure if it the TCP or mafmt package error, but while it's hard to understand which protocol is unix port listening I think it relates to this package.

Unlike websockets transport, TCP fails to dial a /dnsaddr/

🚨 The automated release from the master branch failed. 🚨

I recommend you give this issue a high priority, so other packages depending on you can benefit from your bug fixes and new features again.

You can find below the list of errors reported by semantic-release. Each one of them has to be resolved in order to automatically publish your package. I’m sure you can fix this 💪.

Errors are usually caused by a misconfiguration or an authentication problem. With each error reported below you will find explanation and guidance to help you to resolve it.

Once all the errors are resolved, semantic-release will release your package the next time you push a commit to the master branch. You can also manually restart the failed CI job that runs semantic-release.

If you are not sure how to resolve this, here are some links that can help you:

• Usage documentation
• Frequently Asked Questions
• Support channels

If those don’t help, or if this issue is reporting something you think isn’t right, you can always ask the humans behind semantic-release.

Missing package.json file.

A package.json file at the root of your project is required to release on npm.

Please follow the npm guideline to create a valid package.json file.

Good luck with your project ✨

Your semantic-release bot 📦🚀

Code, providen in readme as an example, is not correct, signatures are different, please fix or add some description for those who just want to copy example and see if it works. (like me)

Due to the implicit return type of dial, the return type is being generated in a non-obvious (and ESM-incompatible) way.

../../node_modules/@libp2p/tcp/dist/src/index.d.ts:9:63 - error TS7016: Could not find a declaration file for module '@libp2p/interface-connection/dist/src'. '/home/cayman/Code/lodestar/node_modules/@libp2p/interface-connection/dist/src/index.js' implicitly has an 'any' type.
  If the '@libp2p/interface-connection' package actually exposes this module, try adding a new declaration (.d.ts) file containing `declare module '@libp2p/interface-connection/dist/src';`

9     dial(ma: Multiaddr, options: DialOptions): Promise<import("@libp2p/interface-connection/dist/src").Connection>;
                                                                ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

@achingbrain Using a variable metric name is a really bad idea this will break dashboards. Metric name should be constant and contain only _ as special character

I don't really see the point for splitting metrics for different ports. Once someone requests that feature we can add a label on the metric per address. But please do not do this now adding extra labels adds cost to metrics at no-one request.

Originally posted by @dapplion in #223 (comment)

Like go-ipfs, so that:

» ipfs daemon
Initializing daemon...
Swarm listening on /ip4/127.0.0.1/tcp/4001
Swarm listening on /ip4/192.168.1.76/tcp/4001
Swarm listening on /ip4/192.168.10.199/tcp/4001
Swarm listening on /ip6/2001:8a0:7ac5:4201:3ac9:86ff:fe31:7095/tcp/4001
Swarm listening on /ip6/2001:8a0:7ac5:4201:3df5:bfc:9493:ea02/tcp/4001
Swarm listening on /ip6/2001:8a0:7ac5:4201:cd74:d1f7:1901:dfce/tcp/4001
Swarm listening on /ip6/::1/tcp/4001
API server listening on /ip4/127.0.0.1/tcp/5001
Gateway (readonly) server listening on /ip4/127.0.0.1/tcp/8080
Daemon is ready

» jsipfs daemon
Initializing daemon...
Swarm listening on /ip4/0.0.0.0/tcp/4001
Swarm listening on /ip6/::/tcp/4001
API is listening on: http://127.0.0.1:5001
Gateway (readonly) is listening on: http://127.0.0.1:8080
Daemon is ready

fiddle in here -> https://github.com/diasdavid/js-libp2p-tcp/blob/master/src/index.js#L50-L68

I've tried to run the example from the readme, but I get the following error:

TypeError: ma.protoNames is not a function
    at EventEmitter.listener.listen ([...]/node_modules/libp2p-tcp/src/listener.js:78:21)

I'm guessing that the api changed and the example is out of date. Could this be fixed, please?

Also, maybe there should be examples that are actually checked on CI to prevent these kinds of issues in the future.

(node:19077) UnhandledPromiseRejectionWarning: Error: invalid ip
    at module.exports (/Users/alex/.nvm/versions/node/v10.17.0/lib/node_modules/ipfs/node_modules/libp2p-utils/src/ip-port-to-multiaddr.js:8:11)
    at module.exports (/Users/alex/.nvm/versions/node/v10.17.0/lib/node_modules/ipfs/node_modules/libp2p-tcp/src/socket-to-conn.js:55:39)
    at Server.net.createServer (/Users/alex/.nvm/versions/node/v10.17.0/lib/node_modules/ipfs/node_modules/libp2p-tcp/src/listener.js:23:20)
    at Server.emit (events.js:198:13)
    at TCP.onconnection (net.js:1520:8)

This can cause applications to crash.

Once tests are ready - https://github.com/diasdavid/abstract-transport

Version 0.3.4 of interface-transport just got published.

This version is covered by your current version range and after updating it in your project the build failed.

As interface-transport is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

Version 0.3.2 of interface-connection just got published.

This version is covered by your current version range and after updating it in your project the build failed.

As interface-connection is a direct dependency of this project this is very likely breaking your project right now. If other packages depend on you it’s very likely also breaking them.
I recommend you give this issue a very high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

Rather than

var Tcp = require('libp2p-tcp')

var tcp = new Tcp()
tcp.createListener(...)
tcp.dial(...)

we could remove the Tcp object and be much more like Node's net module:

var tcp = require('libp2p-tcp')

tcp.createListener(...)
tcp.dial(...)

CI sometimes breaks on this test https://github.com/libp2p/js-libp2p-tcp/actions/runs/3971032097/jobs/6814690159

  1) close server on maxConnections
       reject dial of connection above closeAbove:
     Socket[1] connect ECONNREFUSED ::1:9900
  Error: connect ECONNREFUSED ::1:9900
      at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1487:16)

The test is supposed to allow the first 3 connections (socket[1], socket[2], socket[3]). However, the first attempted socket fails to connect as apparently the server is not listening. The server should listen here and this promise resolve only when sockets can connect.

From what I can see in the test, the error message comes from this line. The socket is created here and attempts to connect to the port listened on here, so the .listen function may be returning before the socket is fully open? Maybe something OS-specific?

The libp2p-nodetrust server crashed because of an incoming TCP connection.
Unsure what caused this.

Logs:

2018-06-14T19:01:26.104Z libp2p:tcp:listen new connection /ip4/185.156.177.133/tcp/26907
2018-06-14T19:01:26.148Z libp2p:tcp:listen new connection /ip4/185.156.177.133/tcp/27966
Error: invalid ip address
    at ip2buf (/home/maciej/libp2p-nodetrust/server/node_modules/libp2p-tcp/node_modules/multiaddr/src/convert.js:72:32)
    at Function.convertToBuffer [as toBuffer] (/home/maciej/libp2p-nodetrust/server/node_modules/libp2p-tcp/node_modules/multiaddr/src/convert.js:49:14)
    at /home/maciej/libp2p-nodetrust/server/node_modules/libp2p-tcp/node_modules/multiaddr/src/codec.js:85:35
    at arrayMap (/home/maciej/libp2p-nodetrust/server/node_modules/lodash.map/index.js:140:21)
    at map (/home/maciej/libp2p-nodetrust/server/node_modules/lodash.map/index.js:1836:10)
    at stringTuplesToTuples (/home/maciej/libp2p-nodetrust/server/node_modules/libp2p-tcp/node_modules/multiaddr/src/codec.js:79:10)
    at stringToBuffer (/home/maciej/libp2p-nodetrust/server/node_modules/libp2p-tcp/node_modules/multiaddr/src/codec.js:171:13)
    at Object.fromString (/home/maciej/libp2p-nodetrust/server/node_modules/libp2p-tcp/node_modules/multiaddr/src/codec.js:178:10)
    at ClassIsWrapper.withIs.proto.className (/home/maciej/libp2p-nodetrust/server/node_modules/libp2p-tcp/node_modules/multiaddr/src/index.js:40:25)
    at new Multiaddr (/home/maciej/libp2p-nodetrust/server/node_modules/class-is/index.js:40:33)
    at withIs.proto.className (/home/maciej/libp2p-nodetrust/server/node_modules/libp2p-tcp/node_modules/multiaddr/src/index.js:26:12)
    at Multiaddr (/home/maciej/libp2p-nodetrust/server/node_modules/class-is/index.js:40:33)
    at module.exports (/home/maciej/libp2p-nodetrust/server/node_modules/libp2p-tcp/src/get-multiaddr.js:23:10)
    at Server.net.createServer (/home/maciej/libp2p-nodetrust/server/node_modules/libp2p-tcp/src/listener.js:27:18)
    at emitOne (events.js:116:13)
    at Server.emit (events.js:211:7)
    at TCP.onconnection (net.js:1565:8)

More details: https://sentry.zion.host/share/issue/b1f38bc0602b46bd948b18bdb8c91523/

const Libp2p = require('libp2p')
const TCP = require('libp2p-tcp')
const Bootstrap = require('libp2p-bootstrap')
const MPLEX = require('libp2p-mplex')
const { NOISE } = require('libp2p-noise')
const PeerId = require('peer-id')

async function main () {
  const peerId = await PeerId.create()
  const bootstrapList = [
    '/dnsaddr/bootstrap.libp2p.io/p2p/QmcZf59bWwK5XFi76CZX8cbJ4BhTzzA3gU1ZjYZcYW3dwt',
    '/dns4/node0.preload.ipfs.io/tcp/443/wss/p2p/QmZMxNdpMkewiVZLMRxaNxUeZpDUb34pWjZ1kZvsd16Zic'
  ]

  const node = new Libp2p({
    peerId,
    addresses: {
      listen: []
    },
    modules: {
      transport: [
        TCP
      ],
      streamMuxer: [
        MPLEX
      ],
      connEncryption: [
        NOISE
      ],
      peerDiscovery: [
        Bootstrap
      ]
    },
    config: {
      peerDiscovery: {
        bootstrap: {
          interval: 30e3,
          enabled: true,
          list: bootstrapList
        }
      }
    }
  })

  console.info('starting')
  await node.start()
  console.info('stopping')
  await node.stop()
}

main()

{
  "dependencies": {
    "libp2p": "^0.30.7",
    "libp2p-bootstrap": "^0.12.1",
    "libp2p-mplex": "^0.10.0",
    "libp2p-noise": "^2.0.1",
    "libp2p-tcp": "^0.15.1",
    "peer-id": "^0.14.3"
  }
}

$ node index.js 
starting
stopping   <-- hangs here

Comment out '/dnsaddr/bootstrap.libp2p.io.. or change to '/dns4/bootstrap.libp2p.io... and the process exits as expected.

Does not happen with libp2p-websockets as a transport, only libp2p-tcp.

We had an issue with the default configs on libp2p-js here and found that its because the default timeout is too short on js-libp2p-tcp.

I have 2 questions:
1- Is there any reason that the default timeout is too short? What's wrong with no timeout by default?

2- Is it safe to disable timeouts?

Currently, stream-to-it has a memory leak in sink (and thus duplex) resulting in O(n) memory consumption on the sender side. The leak seems seems to live at least for the entire connection, and possibly after the connection is closed as well.

Calling conn.close() twice (without awaiting) will result in the second call hanging.

The problem is that if socket.end(cb) is called multiple times before the callback is executed, only the first callback will be executed.
Since the promise resolves in the callback, only the first conn.close() will resolve.

The socket.on('close', cb) callback will be triggered for both invocations, cancelling the timeout that provides the only other path to resolve the promise.

Here is a realistic-ish testcase showing how this may be an issue:

const Libp2p = require('libp2p')
const TCP = require('libp2p-tcp')
const MPLEX = require('libp2p-mplex')
const { NOISE } = require('libp2p-noise')

async function createNode() {
  return Libp2p.create({
    modules: {
      transport: [TCP],
      streamMuxer: [MPLEX],
      connEncryption: [NOISE],
    },
    addresses: {
      listen: ["/ip4/127.0.0.1/tcp/0"],
    },
  })
}

(async function () {
  // create nodes
  const nodes = await Promise.all(Array.from({length: 2}, createNode))

  // start nodes
  await Promise.all(nodes.map(n => n.start()))

  // connect node 0 to node 1
  nodes[0].peerStore.addressBook.add(nodes[1].peerId, nodes[1].multiaddrs)
  await nodes[0].dial(nodes[1].peerId)

  // hangUp and stop
  nodes[0].hangUp(nodes[1].peerId) // not awaited
  await Promise.all(nodes.map(n => n.stop()))

  // will hang, never complete
  console.log('will hang, never complete')
})()

As here described, I was trying to use this module in the browser, but it seems not working.

Here is my code.

And the result is:

Version 2.2.1 of multiaddr just got published.

This version is covered by your current version range and after updating it in your project the build failed.

As multiaddr is a direct dependency of this project this is very likely breaking your project right now. If other packages depend on you it’s very likely also breaking them.
I recommend you give this issue a very high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

Testing Lodestar in a powerful CI we've observed a massive leak of active handles originating at our p2p port (9000). Lodestar uses only the TCP transport, thus I'm opening the issue here.

The peer count however is stable at 25, and running wtfnode in that situation returns ~600 - 25 lines with:

- Sockets:
  - 192.168.16.2:9000 -> undefined:undefined
  - 192.168.16.2:9000 -> undefined:undefined
  - 192.168.16.2:9000 -> undefined:undefined
  - 192.168.16.2:9000 -> undefined:undefined
  - 192.168.16.2:9000 -> undefined:undefined
  - 192.168.16.2:9000 -> undefined:undefined
  - 192.168.16.2:9000 -> undefined:undefined

From wtfnode source and NodeJS net docs that indicates sockets in an intermediate not-connected state. My guess is that TCP does not handle some edge cases and sockets are left hanging.

Have you experienced something like this in your application? This is a big issue for Lodestar since we are very resource constraint.

CC @wemeetagain

Used here

Version 2.2.2 of multiaddr just got published.

This version is covered by your current version range and after updating it in your project the build failed.

As multiaddr is a direct dependency of this project this is very likely breaking your project right now. If other packages depend on you it’s very likely also breaking them.
I recommend you give this issue a very high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

Version 0.3.1 of interface-connection just got published.

This version is covered by your current version range and after updating it in your project the build failed.

As interface-connection is a direct dependency of this project this is very likely breaking your project right now. If other packages depend on you it’s very likely also breaking them.
I recommend you give this issue a very high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

When closing a listener, all the underlying connections are dropped.

Instead, this should behave like webrtc-star, where the peer connections are maintained. (in Webrtc-star, the severed connection is to the discovery service, effectively preventing from knowing new peers.)

Hello,

due to current development and ongoing implementation over at 3box regarding IPFS native running on react-native we found out that whenever we tried to create a libp2p-tcp instance the react-native-tcp android plugin died with an exception regarding java.lang.String cannot be cast to java.lang.Double

After alot of investigation we found that the solution was to implicit convert the port via parseInt(options.port).
Now there are 2 possible solutions:

• change react-native-tcp to check if the incomming port is a string and convert it
• change libp2p-tcp to provide the port as integer/number instead of string

If you say that libp2p-tcp won't change their behavour then I'll have to try to file a issue against the react-native library.

Is it cleaner to provide integer or string in this case tho? Maybe this is an extended issue to multiaddr?

Please let me know how you want us to proceed. Manually patching node_modules libraries is no fun. :-(

This sometimes happens during CI for js-IPFS, usually after a test has passed and it's tearing down the nodes in an after or afterEach block.

ipfs: [stdout] Error: write EPIPE
ipfs:     at afterWriteDispatched (internal/stream_base_commons.js:154:25)
ipfs:     at writeGeneric (internal/stream_base_commons.js:145:3)
ipfs:     at Socket._writeGeneric (net.js:784:11)
ipfs:     at Socket._write (net.js:796:8)
ipfs:     at doWrite (_stream_writable.js:403:12)
ipfs:     at writeOrBuffer (_stream_writable.js:387:5)
ipfs:     at Socket.Writable.write (_stream_writable.js:318:11)
ipfs:     at /Users/travis/build/ipfs/js-ipfs/node_modules/stream-to-it/sink.js:90:21
ipfs:     at processTicksAndRejections (internal/process/task_queues.js:97:5)
ipfs:     at async sink (/Users/travis/build/ipfs/js-ipfs/node_modules/libp2p-tcp/src/socket-to-conn.js:31:9) {
ipfs:   errno: 'EPIPE',
ipfs:   code: 'ERR_UNSUPPORTED_PROTOCOL',
ipfs:   syscall: 'write'
ipfs: }

This is with [email protected].

Currently with the move to Travis CI, testing IPv6 addresses are unreliable.

What happened:
I am following the getting started tutorial https://docs.libp2p.io/tutorials/getting-started/javascript/ to step Transports and getting a type error from a minimal example.

What is expected:
To be able to run the code without issues.

Reproduced minimal code example: https://stackblitz.com/edit/node-dsuzra?file=index.ts

import { createLibp2p } from 'libp2p';
import { TCP } from '@libp2p/tcp';

const main = async () => {
  const tcp = new TCP();
  const node = await createLibp2p({
    transports: [tcp],
  });
};

main();

// package.json
{
  "name": "node-starter",
  "version": "0.0.0",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "dependencies": {
    "@libp2p/tcp": "^3.0.2",
    "libp2p": "^0.37.3",
    "typescript": "^4.7.4"
  }
}

cOpts will be either a string (in case we are using an IPC connection) or an object (in case we are using a network socket)

Hence, for IPC connections, the following code will fail since host and port are not defined.

Description

• lodestar is trying @libp2p/tcp 3.0.3 and notice that sockets are retained in process._getActiveHandles(), in the last 7 days:

• The debugger shows that most of these sockets are inbound and they are not destroyed

Built index.d.ts file break a Typescript build with

node_modules/libp2p-tcp/dist/src/index.d.ts:2:1 - error TS2309: An export assignment cannot be used in a module with other exported elements.
2 export = _exports;
  ~~~~~~~~~~~~~~~~~~
Found 1 error.
error Command failed with exit code 2.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

Link to a CI run with error above https://github.com/ChainSafe/lodestar/pull/3059/checks?check_run_id=3494564063#step:5:52

The file index.d.ts is:

lodestar$ cat node_modules/libp2p-tcp/dist/src/index.d.ts
declare const _exports: any;
export = _exports;
export type Multiaddr = import('multiaddr').Multiaddr;
export type Connection = import("libp2p-interfaces/src/connection/connection");
export type Upgrader = import('libp2p-interfaces/src/transport/types').Upgrader;
export type Listener = import('libp2p-interfaces/src/transport/types').Listener;
export type Socket = import('net').Socket;
//# sourceMappingURL=index.d.ts.map

Blocks ChainSafe/lodestar#3059