Filter
Top Products
30
The
radiogram
protocol provides datagram-based communication between two devices. This
protocol provides no guarantees about delivery or ordering. Datagrams sent over more than one hop
could be silently lost, be delivered more than once, and be delivered out of sequence. Datagrams
sent over a single hop will not be silently lost or delivered out of sequence, but they could be
delivered more than once
4
.
The protocols are implemented on top of the MAC layer of the 802.15.4 implementation.
The radiostream protocol
The
radiostream
protocol is a socket-like peer-to-peer protocol that provides reliable, buffered
stream-based IO between two devices.
To open a connection do:
RadiostreamConnection conn = (RadiostreamConnection)
Connector.open("radio://<destinationAddr>:<portNo>");
where
destinationAddr
is the 64bit IEEE Address of the radio at the far end, and
portNo
is a port
number in the range 0 to 255 that identifies this particular connection. Note that 0 is not a valid
IEEE address in this implementation. The connection is opened using the default radio channel and
default PAN Id (currently channel 26, PAN 3). The section Radio properties shows how to override
these defaults.
To establish a bi-directional connection both ends must open connections specifying the same
portNo
and corresponding IEEE addresses.
Once the connection has been opened, each end can obtain streams to send and receive data, for
example:
DataInputStream dis = conn.openDataInputStream();
DataOutputStream dos = conn.openDataOutputStream();
Here's a complete example:
Program 1
RadiostreamConnection conn = (RadiostreamConnection)
Connector.open("radio://0014.4F01.0000.0006:100");
DataInputStream dis = conn.openDataInputStream();
DataOutputStream dos = conn.openDataOutputStream();
try {
dos.writeUTF("Hello up there");
dos.flush();
System.out.println ("Answer was: " + dis.readUTF());
} catch (NoRouteException e) {
System.out.println ("No route to 0014.4F01.0000.0006");
} finally {
dis.close();
dos.close();
conn.close();
}
4
One aspect of the current behaviour that can be confusing occurs if a SPOT that was communicating over a single hop
closes its connection but then receives a packet addressed to it. In this case the packet will be acknowledged at the
MAC level but then ignored. This can be confusing from the perspective of another SPOT sending to the now-closed
connection: its packets will appear to be accepted because they were acknowledged, but they will not be processed by
the destination SPOT. Thus connections working over a single hop have slightly different semantics to those operating
over multiple hops; this is the result of an important performance optimisation for single hop connections.