Newsgroup: it.comp.reti.wireless
Titolo: [CL] AX25

Mi spiegate come funziona questo protocollo, lo possiamo adattare ad un
qualsiasi dispositivo seriale??
Come fa ad accorgersi se avviene una collisione?
--
Posted from 
ma...@asterix.floating.net
 [212.210.121.64]
via Mailgate.ORG Server - 
http://www.mailgate.org

Come fa ad accorgersi se avviene una collisione?
Come fa un CB per capire se e' stato sovramodulato! :-)
Ovvero: se quando rilasci il microfono "senti" una portante, allora aspetti
un tempo casuale, dipendente da un parametro del TNC (questo parametro e'
importante, dato che se TUTTI hanno lo stesso, allora le collisioni
avvengono piu' frequentemente), poi ci riprovi.
Problema non da poco: i casi peggiori di collisioni avvengono quando una
stazione "vede" diciamo, due altre stazioni *che non si vedono a vicenda*.
Comunque in complesso non e' male, considerato che puoi far sopravvivere
svariate connessioni contemporanee su un unico canale.
Il TNC "tipo Baycom", anziche' essere un TNC fatto e finito, usa il PC ed un
adattatore (solitamente attaccato alla parallela per questioni pratiche) per
funzionare.
Questa e' la pratica, ora spero che qualcun altro pubblichi la teoria. :-)
Fabrizio

 
Cioe' esattamente come fa una scheda ethernet!
-- 
Mario Giammarco 
giam...@cs.unibo.it
mgiam...@racine.ra.it
 
mgiam...@libero.it
Via Calamandrei, 5 -48022 Lugo (RA) 0545/22965-ITALY

Come fa ad accorgersi se avviene una collisione?
Esegue il checksum dei pacchetti in arrivo, se non 
corrisponde manda un pacchetto NAK e la stazione che e' andata in 
collisione aspetta un intervallo di tempo casuale prima di 
ritrasmettere.
Non e' necessario che tutte le stazioni si sentano , e possono
(anzi *devono*) convivere tutte nel medesimo canale.
IMHO AX.25 e' un protocollo superiore nel gestire le collisioni.
Inoltre il suo ottimo funzionamento e' stato dimostrato 
anche a velocita' molto elevate, tipo 1.2Mbps.
AX.25 inoltre supporta l'utilizzo di altre stazioni vecine per usarle
come relay stations in modo trasparente.
Il tutto funziona sino a 7 hops differenti, ma nulla vieta di 
modificare questo valore.
In alternativa si puo' fare relay a livello TCP/IP nel modo classico,
disincapsulandolo nella stazione gateway.
AX.25 e' incredibilmente flessibile da questo punto di vista.
Spero di averti convinto che secondo me e' questo il protocollo
giusto.
 

Direi che sto AX25 e' veramente ottimo la domanda che vi faccio e'
implementabile ad esempio con il laser link???
Se costruiamo un dispositivo veloce da circa 1 Mb/s  l'efficienza  aumenta
perche' il numero dei dispositivi e' lo stesso e quindi in teoria anche il
numero delle collisioni, ma il tutto andra' piu' veloce.
Quindi se costuriamo un dispositivo che usa la seriale veloce raggiungendo gli
768Kb/s abbiamo risolto il problema
Giuseppe


 >


768Kb/s abbiamo risolto il problema
Originariamente il Baycom era subito dietro l'IRDA ed i DECT adattati, nella
lista dei "papabili".
Pensa che non hai piu' bisogno di fare folli modulazioni per i laser link,
ma pero' un po' mi preoccupa il fatto che quasi nessuno dei laser link si
"vede"... le collisioni sono decisamente maggiori.
Forse un protocollo ad interrogazione?
Fabrizio

768Kb/s abbiamo risolto il problema
Per adesso la mia interfaccia seriale dovrebbe arrivare fino a 384Kbps
sostituendo il MAX232A.
Cambiando un paio di componenti nel driver laser dovrei arrivare senza
problemi a 768K.
Mettero' queste info nel disegno del circuito.

"vede"... le collisioni sono decisamente maggiori.
Se costringessimo il server trasmettere in duplex e in realtime cio'
che riceve allora tutti vedrebbero tutti.
Questo non e' affatto necessario con l'AX.25, ma migliorerebbe
l'efficienza. E comunque ho dei dubbi sul duplex.
Certo che con otto utenti per porta, 768Kbps di banda e il fatto che 
'sti otto utenti non saranno tutti attivi allo stesso momento penso
proprio che la trasmissione non si degradi troppo.
A proposito, la MTU dell'AX.25 e' gia' abbastanza piccola 
da migliorare le cose.
E poi contiamo il fatto che alla fine e' il server a trasmettere la 
maggior mole di dati.
I client trasmettono pachetti molto piu' piccoli e questo ci 
favorisce!
 

 Si.
esatto... ma dato che stiamo facendo tutto da 0 che ne pensate di progettare
anche il protollo???  dato che l'ax.25 comincia ad avere i suo annetti....
diciamo che non è dei più evoluti... non so' neanche se gestisce il
controllo di flussso sliding-windows... penso che usi roba tipo
stop-and-wait..... 'spetta che controllo sul libro mastro delle TLC...
allora... innanzitutto l' X.25  che non è altro che il protocollo da cui
deriva l'Ax.25 è esattamente del 1976!!!!  è del 3° livello OSI (livello
rete).... ...  ok.. cazzata... ha controllo di flusso sliding-windows...
però non mi piace la tecnica di indirizzamento (IDN) che sfrutta 4 numeri
per identificare la nazione e la "rete" puù altri (mi sembra) 12 per il n°
utente.... in pratica usa un indirizzamento UNIVOCO simile al TCP/IP con la
sola differenza che per il secondo ci sono miriadi di proxy... ecc. ecc.
meno male che nell'AX.15 è stato ridisegnato il sistema di indirizzamento
(per usare i nominativi OM!!!)  ma è ancora un po'.... come dire....
antico... diciamo che le collisioni vengono gestite di merda..... anzi quasi
non vengono "capite".... si sà solo che un certo numero di pacchetti è
andato perso... ma non so' se faccia il roll-back al pacchetto perso e poi
continui o ritrasmetta partendo dal pacchetto perso tutto!!!....  nzomma...
non mi piace...
Un  bel protocollo sarebbe uno che dinamicamente conosce il traffico della
rete (capisco che non se ne occupa il 3° livello OSI... ma si potrebbe
proprio ignorare la pila OSI... mi basta avere un'accesso al 5° livello che
poi il resto si fa' tutto insieme.....)...  e "a turno" ogni nodo possa
"dire la sua" e "comandare sui vicini" per un  periodo T fissato in base
alla sua "stabilità / velocità  / importanza".
Es. ho 5 nodi...    A,B,C,D,E    distribuiti su 2 sottoreti {A,B,C}, {D,E}
C e D sono due gateway interconnessi per far "dialogare" le due sottoreti
 C e D potrebbero essere 2 noti con un fattore di Importanza maggiore di un
nodo semplice... quindi potrebbero avere il diritto di dire la loro su chi
può accedere al mezzo trasmissivo.... in pratica si possono avere dei token
(si si... proprio come quelli della Token-ring) che il sistema "capo" (che
in questo caso può essere C) distribuisce tra i nodi....  un nodo non può
parlare mentre un'altro lo stà già facendo e mentre non ha token....  in un
token potrà essere contenuta (portebbe essere un pacchetto di controllo di
tipo broadcast) l'esatta sequenza che debbono avere i nodi... del tipo prima
A poi B e poi C.... magari per trasmettere a B un nuovo token e assieme al
token la conferma di un pacchetto inviato a E......   chissà!!!...
Cmq mi son reso conto ora che tutto sto' ragionamento non serve ad un
CAZZO!!!!....    scusate ma se risolviamo il tutto con link point to
point.....  USIAMO IL PPP e basta!!!   intanto c'è la lente magica a
divideri i fasci e risolvere le "ventuali" collisioni!!  CIAOOO
--
Alberto G.
E-mail =========>  
san...@libero.it
Fast E-Mail=====> 
san...@mail.omnitel.it


da migliorare le cose.
da 1 a 255 byte, se ben ricordo... tipicamente, 128.
Fatto apposta per piccoli baud rate... penso che noialtri potremo mettere
comodamente 255.
(gia' lo fanno a 1200 in packet tra stazioni vicine e stabili)
Fabrizio




Non andra' mai !
...QUALE baycom? Mi pare che vi siano numerose versioni, quella da 768K e'
quella di punta... non starai pensando a quella a 1200 bps per packet senza
TNC, vero?
Fabrizio

Non andra' mai !
Ovvio, se parli del baycom seriale, ma io sto parlando dell' EPPflex
che viaggia sulla porta parallela in modalita EPP totalmente diverso
da cio' a cui pensi tu.