go-libp2p/examples/multipro
Marten Seemann b7bee3855c remove the context from the libp2p and from the Host contructor 2021-09-18 14:06:56 +02:00
..
pb doc(examples): remove incorrect readme 2021-05-12 10:16:48 -07:00
.gitignore Add .gitignore for each example 2021-05-10 11:54:35 +01:00
AUTHORS chore: bring examples back into repository 2021-05-05 10:57:48 +01:00
LICENSE chore: bring examples back into repository 2021-05-05 10:57:48 +01:00
README.md Fix up example readmes, submodules and gitignore 2021-05-05 11:32:17 +01:00
echo.go fix: deflake multipro echo test 2021-08-03 13:36:29 -07:00
main.go remove the context from the libp2p and from the Host contructor 2021-09-18 14:06:56 +02:00
main_test.go chore: add tests for examples 2021-05-07 14:52:47 +01:00
node.go chore: update deps 2021-07-28 14:28:57 +02:00
ping.go fix: deflake multipro echo test 2021-08-03 13:36:29 -07:00

README.md

Protocol Multiplexing using rpc-style protobufs with libp2p

This example shows how to use protobufs to encode and transmit information between libp2p hosts using libp2p Streams. This example expects that you are already familiar with the echo example.

Build

From the go-libp2p/examples directory run the following:

> cd multipro/
> go build

Usage

> ./multipro

Details

The example creates two libp2p Hosts supporting 2 protocols: ping and echo.

Each protocol consists of RPC-style requests and responses and each request and response is a typed protobufs message (and a go data object).

This is a different pattern than defining a whole p2p protocol as one protobuf message with lots of optional fields (as can be observed in various p2p-lib protocols using protobufs such as dht).

The example shows how to match async received responses with their requests. This is useful when processing a response requires access to the request data.

The idea is to use libp2p protocol multiplexing on a per-message basis.

Features

  1. 2 fully implemented protocols using an RPC-like request-response pattern - Ping and Echo
  2. Scaffolding for quickly implementing new app-level versioned RPC-like protocols
  3. Full authentication of incoming message data by author (who might not be the message's sender peer)
  4. Base p2p format in protobufs with fields shared by all protocol messages
  5. Full access to request data when processing a response.

Author

@avive