Dev In-Depth: Send Acknowledgement


#1

Send Acknowledgment is just one of several software stories that got completed recently. In this new section of ‘Dev In-Depth’ we will try to shine a bit more light on what it is actually about, why it matters and how it works. Feel free to comment, or ask questions!

The aim of ‘Send Acknowledgement’ is to increase fault tolerance in routing when a message is passed on through the SAFE network.

Perhaps a short recap is in order first. In the SAFE network, messages are forwarded thanks to the address space with a XOR distance measure. A message is always destined for a specific nodeID. At routing level we don’t care whether it’s a MAID, PMID or other ID, so any ID is captured by the more general nodeID class. A node that receives a message for another nodeID will look through the list of all the nodes it knows of. Thanks to the XOR distance it can efficiently calculate which of these nodes is closest to the destination target, and send the message on. This way we have no need to flood the network with messages, hoping to reach the target; we know we will converge onto it efficiently.

The SAFE network also guarantees that your messages don’t get lost along the way. Messages in the SAFE network can be up to 2MB in size. (RUDP will break them up further into packets of 65kB.) This means we can’t just store the messages on all nodes it passed along its route, when would it be appropriate to clean them out? This is where ‘send acknowledgement’ plays its part.

Let’s follow one message along while it hops from node to node, increasingly closer to its destination. Reliable UDP (the layer underneath Routing) already reports back to the previous node that it received all RUDP packets correctly. When a node has forwarded a message successfully onto to the next node, it knows this through all the successfully sent RUDP packets for that message. The node will now send a Routing message back, a ‘Routing acknowledgment’ if you will, to it’s previous node.

Why is this important? The previous node knows that when it receives the Routing acknowledgment message the next and second next node now have a full copy of the message. Once acknowledged, the node can now forget about that routing message. There are always two full copies of the message further along in the network. If a message transfer fails at any point, the message can always continue along a new route. With ‘send acknowledgement’ the network achieves this in the most efficient way.

Let us know of what you think of the new format, and be sure to ask questions or comment !

Cheers
Ben


Dev Update - Sprint 2 - 8 September - 28 September
#2

When I read things like this and it’s clicking all I think is “wow this is brilliant” the whole thing. The simplicity of its functioning but yet appreciating the (I’m assuming) complexity of arriving at these solutions puts a grin on my face.


#3

Great! Good to learn some more in-depth things about Maidsafe. I have 2 questions.

  1. What about caching?? When does this happen?
  2. Can you help me out with this subject below? I tried to figure out things like these but don’t know if I’m correct…

[Starting the Maidsafeclient][1]
[1]: What happends when I start my Maidsafeclient?


#4

Caching happens on save/get of immutable data chunks. The larger question is probably better answered by following the examples projects from the docs part of the website. It’s jumping forward a wee bit and will cause lots of delays going over it all I think. The examples should start properly again they were badly delayed with us altering rudp and routing and getting the team expanded.

There are some details on the wiki regarding starting a local network etc. though if that helps.


#5

Seems like the docs are updated:

Nice going!;
http://maidsafe.net/SystemDocs/!;