public inbox for b.a.t.m.a.n@lists.open-mesh.org
 help / color / mirror / Atom feed
From: Antonio Quartulli <ordex@autistici.org>
To: Sven Eckelmann <sven@narfation.org>
Cc: b.a.t.m.a.n@lists.open-mesh.org
Subject: Re: [B.A.T.M.A.N.] Combination of flags in tt_query packets
Date: Mon, 13 Jun 2011 19:02:07 +0200	[thread overview]
Message-ID: <20110613170207.GC9787@ritirata.org> (raw)
In-Reply-To: <201106131629.19141.sven@narfation.org>

On Mon, Jun 13, 2011 at 04:29:16PM +0200, Sven Eckelmann wrote:
> Antonio Quartulli wrote:
> > > just looked a little bit closer at your tt_query implementation and was
> > > reminded that we had a small discussion in IRC some weeks ago.
> > > 
> > > <ecsv> can those flags be mixed?
> > > <ordex> mixed? in which way?
> > > <ecsv> request | table -> still a valid package
> > > <ecsv> sry, packet
> > > <ordex> yes it is, because it means "I'm requesting a full table"
> > > <ordex> all the combinations are valid
> > > 
> > > This sounds wrong when I look at the tt_query packet. There we have a
> > > tt_data field which can used used exclusive by either TT_REQUEST (x)or
> > > TT_RESPONSE. Therefore, it is not possible to use both flags at the same
> > > time. Can you please explain how this is handled or otherwise change it
> > > so that only one bit in flags is used to decide if it is an response or
> > > a request.
> > 
> > At the beginning we had one bit only with this meaning:
> > 
> > 0 => TT_REQUEST
> > 1 => TT_RESPONSE
> 
> Could be correct - never followed the discussion in detail. I asked Marek and 
> he said something about roaming.

We did something similar for the tt_change flag field. I think I have to
give a look at it too.


> 
> > But then we had a disussion about:
> > 1) what will we do if we want to add more packet types in the future?
> 
> Depends on the type. For example full-table creates different packet types 
> together with the TT_REQUEST and TT_RESPONSE. But using TT_REQUEST and 
> TT_RESPONSE together doesn't work at all. So forget about the flag and think 
> more about a currently undefined amount of bits which encode the type of 
> packet. Encoding the request and reply in two different bits and call them 
> flags doesn't really make sense. 
> 
> > 2) is it correct or not to use 0x0 as flag?
> 
> A not existing bit position is not really a "flag". The bit at position zero 
> (lsb) could be used as flag to decide if it is a request or a response - but 
> using nothing to store something is... <please insert your favourite swear 
> word here>.
> 
> > Regarding 1) I thought that using a "two bits flag" could help in reserving
> > two configurations more for the future (0x0 and 0x3).
> 
> Then you say that you don't use flags but 2 bits to store 2 values. Please 
> don't use it in your code as flags, but use something like (x & TT_TYPE_MASK) 
> to extract the corresponding bits and compare the resulting values against 
> representation of TT_RESPONSE and TT_RESPONSE (TT_TYPE_MASK would be 0x3, 
> TT_RESPONSE 0 and TT_REQUEST 3). Also remove the TT_RESPONSE and TT_REQUEST 
> from the enum tt_query_flags and use another enum for them.

Ok, I agree. I'm going to propose a patch to clean it up. Thanks for all
the suggestions.

Regards,


-- 
Antonio Quartulli

..each of us alone is worth nothing..
Ernesto "Che" Guevara

      parent reply	other threads:[~2011-06-13 17:02 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-12  9:52 [B.A.T.M.A.N.] Combination of flags in tt_query packets Sven Eckelmann
2011-06-13 13:25 ` Antonio Quartulli
2011-06-13 14:29   ` Sven Eckelmann
2011-06-13 14:30     ` Sven Eckelmann
2011-06-13 17:02     ` Antonio Quartulli [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110613170207.GC9787@ritirata.org \
    --to=ordex@autistici.org \
    --cc=b.a.t.m.a.n@lists.open-mesh.org \
    --cc=sven@narfation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox