From a7ed1f0e9c173290ff8e2b576d75e00085afbf77 Mon Sep 17 00:00:00 2001 From: Matthias Radestock Date: Fri, 16 Jan 2015 16:06:09 +0000 Subject: [PATCH] less willing --- site/how-it-works.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/site/how-it-works.md b/site/how-it-works.md index 08d1c287..94387af8 100644 --- a/site/how-it-works.md +++ b/site/how-it-works.md @@ -88,7 +88,7 @@ The name of the sending peer enables the receiving peer to identify who sent this UDP packet. This is followed by the meta data and payload for one or more captured frames. The router performs batching: if it captures several frames very quickly that all need forwarding to -the same peer, it will fit as many of them as possible into a single +the same peer, it fits as many of them as possible into a single UDP packet. The meta data for each frame contains the names of the capturing and @@ -98,7 +98,7 @@ receiving peers to build up their mappings of which client MAC addresses are local to which peers. The destination peer name enables the receiving peer to identify whether this frame is destined for itself or whether it should be forwarded on to some other peer, -accomodating multi-hop routing. This will work even when the receiving +accomodating multi-hop routing. This works even when the receiving intermediate peer has no knowledge of the destination MAC: only the original capturing peer needs to determine the destination peer from the MAC. This way weave peers never need to exchange the MAC addresses @@ -201,7 +201,7 @@ If the destination peer for a packet is still reachable, then out-of-date topology can result in it taking a less efficient route. If the out-of-date topology makes it look as if the destination peer -is not reachable, then the packet will be dropped. For most protocols +is not reachable, then the packet is dropped. For most protocols (e.g. TCP), the transmission will be retried a short time later, by which time the topology should have updated.