Hi, As far as I understand, the TinyOS does not do buffering at the data link layer (refer to tos/system/AM_*.c*). So if you do one-hop communication without routing, no buffering is available unless you program it. If you design a network layer on the data link layer, it's possible that you can add buffering into the network layer.
A tradeoff is: if one implements buffering in the network layer, the data link layer may not be able to do efficient traffic scheduling because it has only one packet to dispatch. Acturally, in our project I designed a new component -- MSG_POOL -- to manage the storage of messages and a reliable data-link layer component to do buffering and confirmed unicast (source code can be found from http://www.sourceforge.net/projects/vert, the file is tos/system/AM_CONFIRM.c* and tos/system/MSG_POOL.c*). As to mingled packets, in TOS0.6 the packet is dropped. But TOS1.0 may be using a smarter scheme. At least it has positive ACK so the lack of ACK may be treated as a NACK in some appropriate context. As to reliable communication, the aforementioned reliable data link layer component can do that. For unicasts, it confirms packets (piggybacked), retransmit packets when failure occurs, and remove duplicate packets. More information can be found in doc/VERT.tx from sourceforge.net as mentioned above. Another choice is S-MAC, which also implements reliable communication for unicasts, as far as I know. S-MAC also has RTS/CTS which could avoid some collisions. Finally, if you are patient (and brave :-) ), I am developping a collision-free MAC for the sensor network and you are welcome to try it. Good luck! lin -- Lin Gu Univ. of Virginia / Dept. of Computer Science ----- Original Message ----- From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, November 02, 2002 6:50 PM Subject: [Tinyos-users] Message buffering. > Hi, > > I'm currently using TinyOS 0.6.1 (1.0 RF not working on Rene) and have > a few questions on how the OS handles message buffering. From what > I've read, when a message is received, an event is triggered which has > a pointer to the received message. I'm assuming the memory for the > incoming message is allocated dynamically, and when the event > finishes, it returns the pointer to the message so that the memory can > be freed. > > Now assume the mote is in a busy network and receiving many messages. > Events cannot be preempted, so messages start building up in memory. > 1) Is there a limit to how many messages can be held by a mote? Is it > just a function of the memory size, in which case can incoming > messages render a mote unable to allocate variables? > > When an event returns, the memory used by the message is no longer > accessible, so if the message contents are to be stored across > different events, the message must be stored elsewhere. > 2) Is it possible to somehow keep the same memory for a message across > multiple events, say keeping an array of TOS_MsgPtrs in a frame? What > would the event return if this were the case? > > If it is not possible to keep the same memory, and messages have to be > copied into frames, it would mean that enough buffer space would have > to be statically allocated in anticipation of however many messages > can be received in a short time period. With 1KB of memory on Rene > motes, dedicating this much memory and not being able to use it when > the network isn't busy seems like a significant waste of resources. > > > Finally, two question about reliability. > 3) The networking stack has the ability to compute CRCs. Are any > actions taken by the OS if the CRC fails? Are messages with bad CRCs > automatically dropped, or can different actions be defined, e.g. > NACKs? > 4) Is there an acknowledgement based means of communication > implemented in TinyOS to allow two nodes to communicate reliably, or > does this have to be built from the ground up? > > Thanks for your time. I realize that some of these issues are > addressed in the 1.0 tutorial, and vaguely addressed in the 0.6.1 > tutorial, but it would help to have answers directed specifically to > these questions. > > Thanks again, Emerson Farrugia > > > > _______________________________________________ > Tinyos-users mailing list > [EMAIL PROTECTED] > http://mail.Millennium.Berkeley.EDU/mailman/listinfo/tinyos-users > _______________________________________________ Tinyos-users mailing list [EMAIL PROTECTED] http://mail.Millennium.Berkeley.EDU/mailman/listinfo/tinyos-users
