LoRa Brescia

CLIENT BASE

—

da

admin
in

CLIENT_BASE è un ruolo “ibrido”: si comporta da CLIENT per default, ma si comporta da ROUTER solo per i pacchetti “da o verso” nodi marcati come favorite (tipicamente nodi deboli indoor che vuoi “far uscire” meglio verso la rete).

I nodi CLIENT_BASE non sono riconosciuti automaticamente nella rete, il loro comportamento speciale si attiva solo quando il pacchetto è da o verso un nodo favorito (favorite).

  • In pratica: base = nodo con ruolo CLIENT_BASE.
  • client serviti = nodi che la base considera “favoriti” (impostati come preferiti nell’app)

Come “tagga” i messaggi da/verso base

Non aggiunge un “tag” nel payload tipo “sono base”. Il “tagging” è implicito nei campi standard del MeshPacket e negli attributi del sender nel NodeDB:

  • from / to nel pacchetto (chi manda / a chi è destinato)
  • node->user.role (ruolo annunciato dal nodo, quindi anche CLIENT_BASE se la base lo pubblica)
  • node->is_favorite (flag locale nel DB di chi riceve, usato dalla base per decidere come trattare i pacchetti)

Quindi: i pacchetti non diventano “speciali” nel formato, è la base che decide di trattarli diversamente se nodeDB->isFromOrToFavoritedNode(packet) è vero.

Come si comporta “rispetto alla base” (cosa cambia davvero)

Le differenze principali sono nel rebroadcast/relaying (routing/flooding):

1) Rebroadcast “early like router” solo per favoriti

In RadioInterface::shouldRebroadcastEarlyLikeRouter():

  • ROUTER: sempre early rebroadcast
  • CLIENT_BASE: early rebroadcast solo se il pacchetto è da o verso un nodo favorito

Questo fa sì che la base “copra” meglio i nodi favoriti (meno collisioni e più probabilità che il pacchetto prenda la strada giusta).

2) Non cancella il rebroadcast dei pacchetti dei favoriti

In FloodingRouter::roleAllowsCancelingDupe():

  • i client normali tendono a cancellare un rebroadcast se sentono che qualcun altro ha già ritrasmesso (per ridurre airtime)
  • CLIENT_BASE invece si comporta come ROUTER per pacchetti from/to favoriti: non cancella e quindi aumenta la probabilità che il pacchetto venga propagato.

3) Hop-limit preservato in scenari “router ↔ router” (include CLIENT_BASE)

In Router::shouldDecrementHopLimit() (commento in Router.h):

  • per alcuni relay “router-grade” può preservare hop_limit (non decrementarlo) dopo il primo hop quando:
  • il nodo locale è ROUTER/ROUTER_LATE/CLIENT_BASE
  • il relay precedente è un favorite con ruolo router-grade (nel codice: ROUTER/ROUTER_LATE; l’intento include anche base)
    Questo serve a mantenere “energia di hop” quando stai attraversando backbone affidabili.

Interazione con “favorite” e perché è speciale su CLIENT_BASE

Su un CLIENT_BASE, is_favorite ha un significato operativo forte (decide quali nodi “tratto da router”). Per evitare side-effect:

  • quando arrivano contatti via client/app (add_contact), non auto-imposta favorite su CLIENT_BASE (vedi NodeDB::addFromContact): aggiorna last_heard invece, così il nodo non viene subito evictato ma non diventa “servito” per sbaglio.

Cosa NON fa

  • Non crea un canale speciale “verso la base”
  • Non cambia cifratura o addressing dei pacchetti “perché è base”
  • Non “instrada tutto verso la base”: è solo un rebroadcast policy upgrade mirato ai favoriti