|Ron Goldman||Mar 11, 2009 1:37 am|
|John Daniels||Mar 11, 2009 2:01 am|
|Ron Goldman||Mar 11, 2009 2:15 am|
|John Daniels||Mar 11, 2009 2:46 am|
|Markus Bestehorn||Mar 11, 2009 6:24 am|
|Bart Braem||Mar 11, 2009 6:52 am|
|Robert Taylor||Mar 11, 2009 7:24 am|
|John Daniels||Mar 11, 2009 7:56 am|
|Bart Braem||Mar 11, 2009 8:11 am|
|Kurt Smolderen||Mar 11, 2009 11:04 am|
|Ron Goldman||Mar 11, 2009 4:25 pm|
|Ron Goldman||Mar 11, 2009 4:47 pm|
|Ron Goldman||Mar 11, 2009 6:13 pm|
|Ron Goldman||Mar 11, 2009 6:26 pm|
|Stephan Kessler||Mar 16, 2009 12:04 am|
|Subject:||AW: Radio update, update|
|From:||Stephan Kessler (kess...@ipd.uni-karlsruhe.de)|
|Date:||Mar 16, 2009 12:04:41 am|
just some general thoughts: i think that tuning timeouts will not fix unreliability completely in this case. Just set the timeouts "high enough" and you should get 100% reliability, if everything else is correct. Yes, it won't be fast, but this is less important than a working solution.
Your statement is probably correct. However, I don't think we want to see this kind of 'trade-offs' sneaking into the SDK. One has to keep in mind some applications do not have reliability as networking constraint, but - for instance - low-delay.
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...
I don't exactly know how OTA is implemented. The way I see it, L4 (TCP/ UDP or Radiostream/ Radiogram if you prefer) should deal with timeouts if wanted (as this is probably not the case for UDP/ Radiogram). If a timeout (or whatever other non-recoverable failure) occurs, an (IO)exception should be thrown. So in general, I believe the current API is pretty well. Once TCP (and IP) is completely supported by the SunSPOTs, introducing the 'socket' concept might be preferable. [..]
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.
Regards, Stephan Kessler