Tero Kivinen <[email protected]> wrote: > number. Also window size is need only if you have out of order packets, > and you care about replay protection. Both of them are something that > might not be something that constrained device cares.
> For example it might have internal replay protection for the messages
> it sends, so it does not need to care whether there is replays on the
> IPsec level, thus it can drop the whole replay protection checks
> completely. Or it might work on the environment where out of order
> deliver is not possible, thus it can just keep window size to 1.
For instance, if one has a single CoAP session active, then there will be in
essence only one packet in flight in either direction, so maybe there is no
re-ordering possible. (Yes, there can be retransmits)
> On the other hand sender is REQUIRED to send sequence numbers in such
> way they are monotonically incrementing (not necessarely by one), and
> if it has any kind of other monotonically incrementing counter like
> clock, it can use that to generate the sequence numbers and get rid of
> the requirement to store outgoing sequence number to the flash.
I agree that this would work well.
> So as those are not really used in non-constrained devices, I do not
> think there is that big different in constrained devices. Again all of
> this depends on the environment. For example some kind of door sensor
> might want to keep sending packets every n seconds just not to leak out
> when the door was opened and closed, but it might just use real packets
> instead of dummy packets. I.e., it might be configured to send the door
> status every 30 seconds, and in that packet it tells whether door is
> now open or closed, and whether what transitions happened during last
> 30 seconds.
Good point, and this makes the packet the same size as well, and uses less code.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | network architect [
] [email protected] http://www.sandelman.ca/ | ruby on rails [
--
Michael Richardson <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Lwip mailing list [email protected] https://www.ietf.org/mailman/listinfo/lwip
