libp2p / libp2p/js-libp2p-daemon
[Streams] Sending and receiving data
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 17
- Forks
- 11
- PR merge metrics
- No merged PRs in 30d
Description
Hello,
I'm currently trying to write a simple messaging protocol over P2P. Under this protocol, we send a message to a peer and wait for the peer to reply using the stream. My issue is that the first message is sent and the response received without any issue, but any further message is never seen by the peer. I simplified the problem and tried to create a simple echo server to demonstrate the issue.
I modified this test of the JS client by adding a second send to reproduce the issue. The initial test case is a one-shot echo server, now it should send two messages in a row while reusing the stream.
...
// First send and receive
const source = require('it-pushable')()
source.push(data)
const output = await pipe(
source,
stream,
take(1),
toBuffer,
collect
)
source.end()
expect(output).to.eql([data])
// Second send and receive
const source2 = require('it-pushable')()
source2.push(data)
const output2 = await pipe(
source2,
stream,
take(1),
toBuffer,
collect
)
source2.end()
expect(output2).to.eql([data])
})
The second send and receive fails. I'm no JS expert so this may be wrong, let me know. Anyway, I made a similar test using the Python client library here. The test has two variants, one that tries to reuse the same stream and one that closes the stream and opens a new one. The variant that reuses the stream fails on both the JS and Go daemons, and the one that opens a new stream works on the Go daemon but fails on the JS one.
Any opinion on what I'm doing wrong / should be fixed?
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with test/stream.spec.js and the two integration variants in tests/test_p2pclient_integration.py linked in the report. Run the repeated-send cases against the JS and Go daemons, then trace stream reuse and reopening behavior. Done means the reported stream cases have consistent, passing behavior or a documented protocol limitation.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go, javascript, python, typescript
- Domain
- distributed-systems, networking
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100