what is the right way to send a message in chat tokio example

[Sherlock-Holo]

I tried the chat tokio example with a little modify https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=9c1d41fdaba91643fd4ef5da659ec7d7
then I run ./rust_learn, it output

Local peer id: PeerId("12D3KooWL7CeBnxjzXmsG6mxwdaMdi6x6kg8tFa9PZBHc7FJAh9R")
[2022-12-09T06:37:04Z INFO libp2p_mdns::behaviour::iface] creating instance on iface 10.40.159.72
[2022-12-09T06:37:04Z INFO libp2p_mdns::behaviour::iface] creating instance on iface 192.168.255.10
[2022-12-09T06:37:04Z INFO libp2p_mdns::behaviour::iface] creating instance on iface 172.17.0.1
[2022-12-09T06:37:04Z INFO libp2p_mdns::behaviour::iface] creating instance on iface 172.18.0.1
Listening on "/ip4/127.0.0.1/tcp/37031"
Listening on "/ip4/10.40.159.72/tcp/37031"
Listening on "/ip4/192.168.255.10/tcp/37031"
Listening on "/ip4/172.17.0.1/tcp/37031"
Listening on "/ip4/172.18.0.1/tcp/37031"

then I try run another one with ./rust_learn /ip4/127.0.0.1/tcp/37031, it output

Local peer id: PeerId("12D3KooWEZmCGmyzytfqtjm98c78Wuw57W3oP7nGsEFTxauUibdx")
Dialed "/ip4/127.0.0.1/tcp/37031"
[2022-12-09T06:38:05Z INFO libp2p_mdns::behaviour::iface] creating instance on iface 10.40.159.72
[2022-12-09T06:38:05Z INFO libp2p_mdns::behaviour::iface] creating instance on iface 192.168.255.10
[2022-12-09T06:38:05Z INFO libp2p_mdns::behaviour::iface] creating instance on iface 172.17.0.1
[2022-12-09T06:38:05Z INFO libp2p_mdns::behaviour::iface] creating instance on iface 172.18.0.1
Listening on "/ip4/127.0.0.1/tcp/33499"
Listening on "/ip4/10.40.159.72/tcp/33499"
Listening on "/ip4/192.168.255.10/tcp/33499"
Listening on "/ip4/172.17.0.1/tcp/33499"
Listening on "/ip4/172.18.0.1/tcp/33499"
other event ConnectionEstablished { peer_id: PeerId("12D3KooWL7CeBnxjzXmsG6mxwdaMdi6x6kg8tFa9PZBHc7FJAh9R"), endpoint: Dialer { address: "/ip4/127.0.0.1/tcp/37031", role_override: Dialer }, num_established: 1, concurrent_dial_errors: Some([]) }

the first one new output is

other event IncomingConnection { local_addr: "/ip4/127.0.0.1/tcp/37031", send_back_addr: "/ip4/127.0.0.1/tcp/42448" }
other event ConnectionEstablished { peer_id: PeerId("12D3KooWEZmCGmyzytfqtjm98c78Wuw57W3oP7nGsEFTxauUibdx"), endpoint: Listener { local_addr: "/ip4/127.0.0.1/tcp/37031", send_back_addr: "/ip4/127.0.0.1/tcp/42448" }, num_established: 1, concurrent_dial_errors: None }

I press abc in the first one terminal, hope send the message to another one, however that's nothing message receive in the second terminal

how should I do to send a message from one node to another node in the chat tokio example

[thomaseizinger]

Can you share your code in a runnable form please? play.rust-lang.org only allows importing select crates and libp2p is not on that list.

[esotericbyte]

The code is the tokio chat example from my understanding of the OP but i don't understand how it's being executed. I do so with the following in root dir of a clone of the git repo:
cargo run --example chat-tokio --features="full"
in a second split of hyper terminal:
cargo run --example chat-tokio --features="full" -- <localhost multiadder listening address of first instance>
for example from above like:
cargo run --example chat-tokio --features="full" -- /ip4/127.0.0.1/tcp/37031

It's important to keep in mind the chat examples use readline and send one line at a time not one character. You have to press enter to send.
I was testing the various chat examples in linux and windows recently.
I was curious though if any examples may be out of date with breaking changes in the library? I am traveling and can only mess with linux currently.
Anyway second process says it dials but no ACK in the first process
No reflection of lines either way
And I think no firewall but testing that further i just did:
$# sudo ufw status verbose
Status: inactive

[esotericbyte]

The metrics example I was messing to update the http server does connect with the dial and does it's ping pong behavior between processes. It looks like now it has an ipfs id push behavior or is that coming free? I don't remember that from before. Anyway it does not relay chat messages and I believe it use to do so like the asyncio-std "chat" example.
Running this by, from clone root
$cd misc/metrics
$cargo run --example metrics
#--- Second terminal
$cd misc/metrics
$cargo run --example metrics -- <local host multiaddr >

[elenaf9]

Thanks for reporting @Sherlock-Holo. I believe the issue is that the peers are not subscribing to the floodsub topic.
The line for subscribing to the topic was accidentally removed from the chat-tokio.rs example in an unrelated change, sorry about that!
I opened #3296 to add it back. Could you try again with that fix?

[esotericbyte]

I added the subscription code and also reflected code using for the mDNS to add it to the floodsub list of peers. I am not sure if with dial that is an automatic behavior? Do new nodes connected with dial need to be added and removed from floodsub with add_node_to_partial_view as is done with mDNS? Doing so does not raise errors.
There is another issue with dialed connections. Perhaps with others too. I discovered by having it print all events.
ConnectionClosed{ ..... case: Some{KeepAliveTImeout}
Does the example need ping pong to keep the connection open, or is there someplace to set a longer reasonable time out?
Even with subscribe code and partial view code connections are silently dropped by chat and chat-tokio examples.
I have added redial code when connections are dropped by the listener but sometime it's the dialer that drops and this does not feel like the right solution.
I will take a look at #3296 .