Hi Kurt,

Well, you are right, i agree with that! But at "debug-time" it is probably a good idea to eliminate possible errors with this method. More on "low delay" later...

Hm that's correct, I think we mixed up some communication specific terms and therefore our answer was maybe a bit unclear, I'll try to explain in more detail: Let's assume there are 3 SunSPOTS, A<->B<->C. A can't talk to C directly, so B has to route the data to C (just the usual stuff). The routing layer at node A has to determine the route over B. We start transferring the data from A to B and then from B to C. If the last transfer succeeded, an acknowledgement has to be emitted by C in order to inform A of the successful transfer. If A receives this acknowledgement, it can report "true" to its upper layers, and otherwise "false" (well yes it may be a good idea to retry here, but that depends...). If the transfer fails the routing layer should invalidate the route over B in this case.

In my opinion the application API is pretty well (radiostream/radiogram), but I'm not completely happy with the LowPan Interface/Layer. There are some methods like "sendWithoutMeshingOrFragmentation" which clearly destroy the layer principle in the stack. I know it is necessary to make the IRoutingManager interface/concept possible, but if the RoutingManager would be a real routing layer in the stack, this won't be necessary.

I think if we start separating the concerns more cleanly, we will get a more flexible solution. In the KSN RadioStack, the implementation of a new layer is only a few lines of code. For example: the compression layer is (if you're using a zip library) only about 165 lines of code and if you don't count method signatures and imports it would be less than 100. This layer can be combined in every way with the other layers. This also makes it more easy to build up a stack with different optimization idea in mind: for example "low delay". If you want a stack which reacts very quickly, you most likely do not want an AODV routing layer because it is a reactive protocol. According to that you may want the compression layer to reduce the transferred data size, but depending on how long it takes to compress the data, you don't want it. You see, flexibility is very important (even for low delay ;)), and with everything (routing, fragmentation, ...) packed in the LowPan Layer, this is not possible.