fluencelabs/rust-libp2p
1
0
Fork 0
mirror of https://github.com/fluencelabs/rust-libp2p synced 2025-08-01 01:11:58 +00:00
Code Issues Projects Releases Wiki Activity

Fix repeatedly spelling, more and more, add a clarification (#376)

Browse Source 
Correct me if saying "close connections to non-responsive remotes (which would then de-allocate memory for the ping)" is wrong.
This commit is contained in:
James Ray
2018-07-27 18:46:45 +10:00
committed by Pierre Krieger
parent 3d6b1dbc3e
commit 9b233ba3ea
1 changed files with 3 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
ping/README.md
View File

@@ -18,13 +18,13 @@ future that is signalled only when the remote answers. If the remote is not resp
future will never be signalled. future will never be signalled.
For implementation reasons, resources allocated for a ping are only ever fully reclaimed after For implementation reasons, resources allocated for a ping are only ever fully reclaimed after
a pong has been received by the remote. Therefore if you repeatidely ping a non-responsive a pong has been received by the remote. Therefore if you repeatedly ping a non-responsive
remote you will end up using more and memory memory (albeit the amount is very very small every remote you will end up using more and more memory (albeit the amount is very very small every
time), even if you destroy the future returned by `ping`. time), even if you destroy the future returned by `ping`.
This is probably not a problem in practice, because the nature of the ping protocol is to This is probably not a problem in practice, because the nature of the ping protocol is to
determine whether a remote is still alive, and any reasonable user of this crate will close determine whether a remote is still alive, and any reasonable user of this crate will close
connections to non-responsive remotes. connections to non-responsive remotes (which would then de-allocate memory for the ping).
# Example # Example