[serval-project-dev] Implementing a different routing protocol

[Fraser Cadger]

Hi everyone,


It's been a wee while since my last post, but I was quite busy over the
last couple of weeks and am only just turning my attention back to working
with Serval.


 Ok, so I've had a think about how best to implement location update
message (which I'll refer to as beacons), without modifying the existing
message structures. My initial thought was to create a struct called beacon
(or similar) which would contain all of the fields (initially our address,
and the longitude and latitude coordinates + the timestamp of when the
coordinates were recorded) and when we were sending a beacon we would
create an instance of this struct. The downside I thought would be that the
beacon struct would have to be embedded in another packet as a payload, and
so this would mean modifying existing messages (not good) or creating a new
message and adding the struct as a payload which seems wasteful. So at this
point I can't see any advantages in using the struct (except possibly as a
template).


 Instead I thought an approach similar to the node announcements could be
used. A function called overlay_add_beacon() (for instance) could be called
from overlay_init_packet(). The purpose of this would be to create the
beacon message, it would be similar in form to
overlay_route_add_advertisement(). So it would call call
overlay_frame_build_header() to create the frame and then it would need to
place the coordinates in the packet. I think the best way to do this would
be to use a similar method to add_advertisement() which uses
ob_append_byte() to add the best link score and observations to the packet,
and before that overlay_address_append to add the address of the node we
are advertising. However, if we are sending beacons for ourself then we do
not need to append a subscriber address as the packet is obviously about
us. Similarly, add_advertisement() is accessed by calling the callback
function enum_subscribers() which is used to find the next (unadvertised)
subscriber in the tree and the use of enum_subscribers() is obviously not
necessary for sending messages about ourselves.


 Therefore, I was thinking that two types of beacons would be better; i.e.
self_beacon and subscriber_beacon. self_beacon would be similar to a self
announce message while subscriber_beacon would be similar to a node
announcement. This would entail slight differences in how they were sent.
self_beacon could have a method called overlay_add_self_beacon() which
function similarly to overlay_add_selfannouncement() except instead of
calling ob_append_ui32() to add timestamps it would call ob_append_byte()
twice as described above, to add the two coordinates and timestamp (or
would it make more sense to use ob_append_ui32 for this timestamp?) .
However it would not call overlay_address_append. On the other hand,
subscriber_beacon would have a method called (for instance)
add_subscriber_beacon() that would function identically to
overlay_route_add_advertisement(), and would call enum_subscribers() as a
callback to a function called add_beacon() which would be similar to
add_advertisement() except that it would call ob_append_byte to add
coordinates (instead of score and observation), then append the timestamp
but would still use overlay_append_byte() to add the address.


 Both overlay_add_self_beacon() and add_subscriber_beacon() would be called
from overlay_init_packet() inside overlay_queue.c; with
overlay_add_self_beacon() being called after overlay_add_selfannouncement()
and add_subscriber_beacon() being called after
overlay_route_add_advertisements() is called. Hopefully I'm right in
thinking that doing this will mean that the self_beacon messages will go
along with the self_announcement messages and the subscriber_beacon
messages will be along with the corresponding node_advertisement messages
for the same subscriber in the one real packet. Even if they are
'separated' (i.e. we receive a subscriber_beacon without a
node_advertisement for the same subscriber) I could probably still handle
it (i.e. search for that subscriber).


 Other than the above, I think the only other step needed for using the
self_beacon and subscriber_beacon messages would be to add them to
constants.h. Actually, I'm wondering what numbers to use, I noticed 0x10 to
0x70 are taken by existing messages. Should I just use the next numbers up
(0x80 and 0x90), or are there any plans by the Serval team to use those?
I'm assuming these numbers are hex numbers, and as type is an integer
number constants.h maps the message type i.e. OF_TYPE_SELF_ANNOUNCE to its
corresponding hex number?


 There might have been a couple of things I've misunderstood in the above,
but I think the general approach I described should allow for me to add the
beacon messages without causing any conflicts with devices running
different versions or their own routing. Hopefully doing it the way I
described above would mean that such devices would just ignore my beacon
messages as they wouldn't recognise the codes for them and there would be
no complications.


 I intend to start the coding soon, but I'm just thought I'd check to see
if my assumptions are correct and if other people think the way of doing
this makes sense before I jump in. I've not mentioned anything about
dealing with the beacons once they've been received, as I've mainly been
focussing on sending them first. However, I imagine this would involve
updating either the subscriber or node entity for that device to change
location. I'll look into this in more detail while I'm working on sending
the beacons.


 Thanks,


 Fraser

-- 
You received this message because you are subscribed to the Google Groups "Serval Project Developers" group.
To post to this group, send email to serval-project-developers at googlegroups.com.
To unsubscribe from this group, send email to serval-project-developers+unsubscribe at googlegroups.com.
For more options, visit this group at http://groups.google.com/group/serval-project-developers?hl=en.


----- End forwarded message -----
-- 
Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org
______________________________________________________________
ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A  7779 75B0 2443 8B29 F6BE