Initial implementation #1
Conversation
|
Tests are running ok locally, will investigate later why not ok in the actions env. |
Caused connections via the signalling channel to hang as pings are not sent
|
@extremeheat Ready for review |
Move to bedrock-protocl
|
@LucienHH what do you think about porting the serializer / framing code to protodef? It'd align with rest of projects. We don't have to do it in this PR (can be done in another), but curious if there's any blocker there like a missing primitive |
|
@extremeheat Done. Let me know what you think of the implementation. NetherNet does have versioning, currently v4 but not sure if it's worth/possible maintaining all versions? |
| /** | ||
| * Encapsulated data with length prefix | ||
| */ | ||
| Read.encapsulated = ['parametrizable', (compiler, { lengthType, type }) => { |
There was a problem hiding this comment.
This should be defined inside of protodef, but we dont have to block on it
| const { SignalType, SignalStructure } = require('./signalling') | ||
|
|
||
| const { getRandomUint64, createPacketData, prepareSecurePacket, processSecurePacket } = require('./util') | ||
| const { PeerConnection } = require('node-datachannel') |
There was a problem hiding this comment.
Need to figure out how to not requre native deps at some point. It'd be great if we could get something working with WASM if needed
Yes, you can simply create a new protocol.json for version changes. Speaking of which, if it's part of minecraft bedrock protocol any reason to not put this into minecraft-data as a bedrock/1.21.100/nethernetProtocol.json? Assuming each minecraft version will be hard coded to use one version of the transport protocol this should be possible. The specific protocol version can be put as a header field inside the protocol.json. |
|
@extremeheat OK, agree on moving this to minecraft-data, assume we can integrate that in a separate PR? Went ahead and made the other recommended amendments |
Co-authored-by: Copilot <[email protected]>
There was a problem hiding this comment.
Pull Request Overview
Initial implementation of the NetherNet protocol for Node.js, adding client/server functionality with WebRTC-based connections, cryptographic packet processing, and UDP discovery mechanism.
- Complete client/server implementation with RTC-based connections and UDP discovery
- Cryptographic packet encryption/decryption and protocol serialization system
- Test suite covering ping, connection, and kick scenarios
Reviewed Changes
Copilot reviewed 14 out of 15 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
| test/basic.test.js | Comprehensive test suite with ping, connection, and kick tests |
| src/util.js | Utility functions for packet creation and secure packet processing |
| src/signalling.js | WebRTC signalling structure and message types |
| src/server.js | Server implementation with UDP discovery and RTC connection handling |
| src/serializer.js | Protocol serialization/deserialization with packet type definitions |
| src/protocol.json | JSON protocol definition for discovery packets |
| src/crypto.js | AES encryption/decryption and HMAC checksum functions |
| src/connection.js | Connection management with message fragmentation |
| src/compilerTypes.js | Custom protocol compiler types for encapsulated data |
| src/client.js | Client implementation with discovery and RTC connection |
| package.json | Updated dependencies and package name |
| index.js | Main module exports |
| example.js | Basic usage example |
| README.md | Updated documentation with usage examples |
Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
|
Review the following changes in direct dependencies. Learn more about Socket for GitHub.
|
2 participants
No description provided.