Newsgroup: it.comp.reti.wireless
Titolo: [City Lan] La topologia?

Innanzi tutto mi presento, sono di Genova, in passato mi sono interessato
alle comunicazioni con tecnologie ottiche (led IR, diodi laser) per vari
progetti che, purtroppo per scarso tempo libero, sono stato costretto ad
accantonare.
Sono venuto a conoscenza del vostro progetto per un messaggio apparso in un
NG e devo dire che la cosa mi interessa non poco perche' "sfrugugliava"
nella testa da qualche tempo pure a me. In passato utilizzavo il famoso
"baracchino" usando la 27 e dintorni, il mio sogno piu' grande sarebbe stato
quello di mettere insieme un baycom per una piccola rete locale, purtroppo
non avevo ne i mezzi ne le conoscenze adeguate, inoltre non trovavo
corrispondenti con cui condividere l'hobby.
Ad ogni modo mi piacerebbe capire alcune cose che non mi sono ancora molto
chiare, soprattutto riguardo la topologia della rete che si vuole
implementare.
Personalmente ritengo che l'allacciamento ad internet sia un problema
secondario, non fraintendetemi, intendo che puo' tranquillamente avvenire
(in un modo o in un altro) sucessivamente, quando la rete cittadina sara'
piu' o meno funzionante.
L'allacciamento, per assurdo (ma neanche troppo), potrebbe essere fatto
tranquillamente da un nodo qualsiasi della city lan temporaneamente connesso
(ad esempio alla sera) che abbia abilitato un server NAT (per esempio
l'IP-Masquerading sotto Linux) e che, alla peggio, abbia comunicato la cosa
agli interessati in quel momento (questi basta che settino il default
gateway su quell'indirizzo).
In  particolare mi piacerebbe comprendere meglio l'architettura della rete,
per esempio come si vuole far interagire tre e piu' nodi con gli estremi non
adiacenti. Volete sfruttare un meccanismo simile al routing o ognuno dei
nodi deve necessariamente "vedere" *tutti* gli altri? Lo dico perche' qui a
Genova (nella fattispecie) siamo pieni di colline, con relative insenature,
quindi l'idea che mi ero abbozzato in testa era una specie di rete cellulare
in cui ogni host conosce solo i nodi adiacenti (che sono direttamente
raggiungibili) e, quando riceve un pacchetto dall'interfaccia di ricezione
che non e' stato spedito direttamente a lui, procede ripetendolo in tx (in
modo che faccia da ponte).  Una piccolo sistema per propagare i pacchetti
lungo la rete insomma. L'unico problema sono i duplicati (che comunque
dovrebbero essere gestiti abbastanza bene dal TCP) in quanto cosi'
brutalmente e' possibile che piu' nodi ripetitori ricevano il pacchetto e lo
ripetano simultaneamente nella loro zona, nel caso sfigato il destinatario
potrebbe essere raggiungibile da tutti e due i ripetitori ricevendo quindi
il pacchetto due volte.
Qui pero' si apre un interessante disquisizione mica da poco sul modello di
tranceiver da utilizzare. Ottenere l'omidirezionalita' sarebbe l'ideale per
una rete cittadina generica. Purtroppo con i sistemi ottici e' una chimera.
Quindi come regolarsi per le possibili diramazioni della rete?
Ciao
Piergiorgio Trubini.
--
Posted from 
dns1.orsiweb.com
 [151.99.234.2]
via Mailgate.ORG Server - 
http://www.mailgate.org

Quindi come regolarsi per le possibili diramazioni della rete?
Probabilmente bisognera' tirare fuori un sistema per le piccole
distanze ma su angoli elevati.
Piuttosto, se ho tre nodi che si appoggiano ad uno solo, e questi tre
non si vedono, come possono sapere quando e' il loro tunro di
trasmettere?
E' questo il mio piu' grande problema e quello che sto cercando di
risolvere in modo economico.
Nospam

In un articolo, 
nos...@nospam.org
stava parlando di [City Lan] La topologia? e ha scritto:
)On 1 Sep 1999 19:32:46 +0200, Tru...@OrsiWeb.Com (Trubini
)Piergiorgio) wrote:
)>Sono venuto a conoscenza del vostro progetto per un messaggio apparso in un
)>NG
)Quale NG e quale messaggio?
Forse quello che ho messo io in it.comp.linux :-)
)>agli interessati in quel momento (questi basta che settino il default
)>gateway su quell'indirizzo).
)Ci ho pensato.
)Non sarebbe male un sistema automatico.
1/2 giornata di programmazione (piu` 15 gg di debugging :-)
)>potrebbe essere raggiungibile da tutti e due i ripetitori ricevendo quindi
)>il pacchetto due volte.
)Piuttosto uno dei casini che tento di eliminare e' la possibilita' di
)generare dei loop e delle tempeste di pacchetti.
Esistono gli algoritmi... probabilmente qualcuno e` anche implementato nel
kernel di Linux...
)>una rete cittadina generica. Purtroppo con i sistemi ottici e' una chimera.
)>Quindi come regolarsi per le possibili diramazioni della rete?
)Probabilmente bisognera' tirare fuori un sistema per le piccole
)distanze ma su angoli elevati.
)Piuttosto, se ho tre nodi che si appoggiano ad uno solo, e questi tre
)non si vedono, come possono sapere quando e' il loro tunro di
)trasmettere?
Che te ne importa ? Ogni interfaccia viene vista come una interfaccia di
rete TCP/IP ed il PC si occupa di fare il routing nelle diverse destinazioni.
Credo che il processo di routing non introduca piu` di 4-5 ms di ritardo.
Giuseppe
-- 
Giuseppe Zanetti

trasmettere?
Non mi e' molto chiaro, intendi che l'host centrale potrebbe avere
solo un interfaccia per gestire piu' nodi adiacenti? Quindi potrebbe
ricevere i pacchetti contemporaneamente sullo stesso receiver?
Questo in effetti e' un problema. Credo che debba essere risolto dal
protocollo di datalink (non so come viene gestita la cosa con IrDA, ma
suppongo che sia contemplata), comunque la stessa cosa si presenta nei
link radioamatoriali su tcp-ip (piu' stazioni condividono la stessa
risorsa, nel caso, la frequenza) pero' qui inizio a saperne veramente
poco, so che si usa l'AX.25. 
Comunque in genere il ricevitore si accorge della sovrapposizione e
scarta il pacchetto (o genera un nak?), i nodi che hanno causato la
collisione dovrebbero ritrasmettere facendo pero' partire un timer di
valore differente, se si ripresenta di nuovo una collissione (questa
volta con un altro host) la cosa si ripete. Un po' come su ethernet.
Ciao
P.Trubini

Trubini Piergiorgio <Tru...@OrsiWeb.Com> wrote in message
cut..
In passato utilizzavo il famoso
| "baracchino" usando la 27 e dintorni, il mio sogno piu' grande sarebbe
stato
| quello di mettere insieme un baycom per una piccola rete locale, purtroppo
| non avevo ne i mezzi ne le conoscenze adeguate, inoltre non trovavo
| corrispondenti con cui condividere l'hobby.
Belin... (ci siamo già sentiti in mail privata)... anche io voglio il
baycom.. però non hanno più il TCM 3105 a Genova.. sono andato da Microkit,
Echo, Gardella, Benvenuti...  nulla!!!!
| Ad ogni modo mi piacerebbe capire alcune cose che non mi sono ancora molto
| chiare, soprattutto riguardo la topologia della rete che si vuole
| implementare.
| Personalmente ritengo che l'allacciamento ad internet sia un problema
| secondario, non fraintendetemi, intendo che puo' tranquillamente avvenire
| (in un modo o in un altro) sucessivamente, quando la rete cittadina sara'
| piu' o meno funzionante.
| L'allacciamento, per assurdo (ma neanche troppo), potrebbe essere fatto
| tranquillamente da un nodo qualsiasi della city lan temporaneamente
connesso
| (ad esempio alla sera) che abbia abilitato un server NAT
ma su di un server NAT     NON GIRANO ALCUNE APPLICAZIONI CHE RICHIEDONO LA
CONOSCENZA DELL' IP LOCALE...      tipo FTP ICQ ecc...
 (per esempio
| l'IP-Masquerading sotto Linux) e che, alla peggio, abbia comunicato la
cosa
| agli interessati in quel momento (questi basta che settino il default
| gateway su quell'indirizzo).
| In  particolare mi piacerebbe comprendere meglio l'architettura della
rete,
| per esempio come si vuole far interagire tre e piu' nodi con gli estremi
non
| adiacenti. Volete sfruttare un meccanismo simile al routing o ognuno dei
| nodi deve necessariamente "vedere" *tutti* gli altri?
No no.. routing...
 Lo dico perche' qui a
| Genova (nella fattispecie) siamo pieni di colline, con relative
insenature,
| quindi l'idea che mi ero abbozzato in testa era una specie di rete
cellulare
| in cui ogni host conosce solo i nodi adiacenti (che sono direttamente
| raggiungibili) e, quando riceve un pacchetto dall'interfaccia di ricezione
| che non e' stato spedito direttamente a lui, procede ripetendolo in tx (in
| modo che faccia da ponte).
Certo... qui a Genova se non fai cosi'... l'alternativa  è mettere su' un
server per ogni valle e collegarli tramite una backbone tra di loro così da
ottenere buone prestazioni... non sarebbe molto difficile... il + è trovare
l'insediamento di un server che "veda" l'intera valle di competenza...
facendo un esempio, io sono in Alta Valle Sturla... il server posizionato
... diciamo sul monte difronte al Forte Ratti potrebbe coprire
tranquillamente tutta la valle... e addiittura anche il centro...
Pensando di utilizzare i diodi IR con tecnologia IrDA.. il tutto sarebbe
gestito automaticamanete dal livello fisico e di DataLink dell'IrDA (che
gestisce anche la multiplazione del canale per più utenti)....     si
condisce il tutto con un link dedicato alla backbone con gli altri server..
ed ecco il gioco è fatto...
 Una piccolo sistema per propagare i pacchetti
| lungo la rete insomma. L'unico problema sono i duplicati (che comunque
| dovrebbero essere gestiti abbastanza bene dal TCP) in quanto cosi'
| brutalmente e' possibile che piu' nodi ripetitori ricevano il pacchetto e
lo
| ripetano simultaneamente nella loro zona, nel caso sfigato il destinatario
| potrebbe essere raggiungibile da tutti e due i ripetitori ricevendo quindi
| il pacchetto due volte.
No problem... il TCP risolve tutto...
| Qui pero' si apre un interessante disquisizione mica da poco sul modello
di
| tranceiver da utilizzare. Ottenere l'omidirezionalita' sarebbe l'ideale
per
| una rete cittadina generica. Purtroppo con i sistemi ottici e' una
chimera.
Non è vero... metti + trasduttori Ir a, diciamo così, cerchio ed ecco la
copertura di 360°...  poi cmq te li adatti di caso in caso.. se per esempio
bisogna gestire un utente si punta verso di lui un numero suff. di diodi Ir
collegati alla porta IrDA .... il giorno che arriverà un'altro utente basta
aggiungere i diodi Ir e puntarli verso di lui... collegandoli alla stessa
porta IrDA... la quale gestisce i due utenti tramite un PROTOCOLLO A CONTESA
intrgrato proprio nel firmware della scheda stessa.. che, se impostata come
scheda di rete rende il tutto COMPLETAMENTE TRASPARENTE (salvo un
rallentamento dei trasferimenti)...
| Ciao
| Piergiorgio Trubini.
--
Gorni Alberto
e-mail: 
san...@tiscalinet.it
fast e-mail: 
03475...@mail.omnitel.it
- - - - -
EmmeGi / Orologica
 Via Peschiera, 9A / canc.
 16122 GENOVA
 Tel. 010 846 1863 - Fax 010 837 2743
 e-mail: 
emm...@assicomitalia.it
 Web:  
www.assicomitalia.it/emmegi

Dobbiamo decidere il tipo di interfaccia prima di poter realizzare il tutto, la
mia idea sarebbe di realizzare qualcosa di molto simile ad una rete ethernet
questo ci semplificherebbe molto la vita per il semplice motivo che ha gia'
implementato nel sistema la gestione delle collisioni, potremmo vedere il tutto
come se fosse un cavo coassiale dove tutti trasmettono con temporizzazioni
differenziate se avviene una collisione il sistema se ne accorge e ritrasmette il
tutto con temporizzazioni differenti, ovviamente con l'aumentare dei dispositivi
aumenta le probabilita' di collisioni.
Scarterei in partenza la seriale come interfaccia proprio perche' potremmmo
realizzare solo dei link point-to-point, dovremmo implementare due apparati RTX
in piu' per ogni nuovo utente della CL,  aumentando il costo in modo
esponenziale, tralasciando poi il problema del routing da un utente al altro, la
maggior parte degli utenti usano Windows95/98 che ha quanto ne so' non e' in
grado di farlo.
La CL avra' successo solo se sara' disponibile al piu' alto numero di utenti
possibili.
Il nostro dispositivo potrebbe essere una normale estensione di una comune scheda
di rete con interfaccia RJ45, basta trasformare il TX in luce a 10 Mb/s
ricovertirlo in segnale elettrico a 10 Mb/s e' buttarlo nel RX, tutto il resto
verra' fatto dalla scheda di rete,con questo sistema la luce sara' il nostro
cavo, in teoria potremmo usare un qualsiasi protocollo, ovviamente il piu'
indicato e' il TCP/IP.
Rimane un ultimo e non piccolo problema di come estendere il raggio effettivo in
metri della nostra CL visto che le nostre emissioni IR non saranno piu'
point-to-point ma molto diffuse, la risposta e' semplice ogni apparato dovra'
oltre che  trasmettere/ricevere  il segnale luminoso anche ripeterlo con il minor
ritardo possibile, un solo bit di ritardo avrebbe un effetto devastante.
In questo modo se l'apparato "C" e' fuori dalla portata ottica dell' apparato "A"
e viceversa, avranno come bridge completamente trasparente l'apparato "B", quindi
l'apparato "C" ricevera' il segnale credendo che sia stato trasmesso da "A" ma in
realta' e' stato solamente ripetuto.
Con questo metodo broadcast potremmo realizzare reti con migliaia di utenti,
anche se le prestazioni ne risentirebbero pesantemente, ma in teoria e'
fattibilissimo.
A 10 Mb/s la durata i ns dell'impulso e' elettronicamente parlando molto ampia
(100ns), quindi in teoria un dispositivo ripetitore ben progettato non dovrebbe
avere grossi problemi. Potremmo pensarlo in modo completamento analogico come se
fosse un comune amplificatore audio ma in realta' sara' un amplificatore di luce,
non sono pazzo, ma se riduciamo al minimo l'elettronica i ritardi sarano quasi
nulli  quindi il ripetitore dovra' ricevere il segnale luminoso coventirlo in
segnale elttrico che arrivera' direttamente al circuito driver (sottolineo tutto
analogico) del diodo che lo riconvertira' in luce, perdendo cosi pochissimi ns,
per traslare un bit ci dovrebbero volere ad occhio una 10ina di ripetizioni.
Ovviamente con l'aumentare del numero dei dispositivi i nostri 100ns
diventerebbero troppo pochi quindi abbiamo due soluzioni, la prima rallentiamo
paurosamente la rete diciamo di almeno 10 volte scendendo sempre alla nobile
velocita' di 1 Mb/s o altrimenti diminuiamo i dispositvi ripetitori.
Se scartiamo la prima opzione perche' non vogliamo complicarci la vita nel
tentativo di  rallentare le nostre schede di rete (ricordiamoci che il discorso
e' partito dalla loro convenienza nella gestione delle collisioni) l' unica
soluzione che ci rimane e' quella di abbassare il numero dei ripetitori
riducendoli all'essenziale vedendoli un po' come HUB con ognuno un certo numero
di client.
Dopo tutto questo farneticare arriviamo alla deduzione finale (spero che qualcuno
sia riuscito a seguirmi) che bastera' dotare di  ripetitore (chiamiamolo HUB)
soltanto i dispositivi piu' esterni  che non riusciendosi a vedere tra loro non
potranno inescare pericolosi loop, semplificando:
se l'HUB "C" e' fuori dalla portata ottica dell' HUB "A" e viceversa avranno come
bridge completamente trasparente l'HUB "B", quindi l' HUB "C" ricevera' il
segnale credendo che sia stato trasmesso dall' HUB "A" ma in realta' e' stato
solamente ripetuto dall' HUB "B", il tutto si dovrebbe tradurre in una specie di
rete cellulare ottica.
Con questo sistema il problema del routing esiste soltanto nel momento che ci
vogliamo immettere in internet ma un bel proxy/firewall risolvera' tutti i nostri
problemi.
Se mi riesce la prossima settimana vedro' di tradurre questi concetti espressi in
disegni per cercare di chiarirla a tutti.
ciao Giuseppe
P.S. non e' detto che dopo tutto questo ragionare io abbia ragione e sia sulla
giusta strada pero' fatemi sapere
--
Posted from 
ma...@dns.floating.net
 [212.210.121.64]


grado di farlo.
Credo che non sia cosi' semplice, l'idea di attaccare un adattatore
ottico ad una scheda ethernet non e' malvagia ma funzionerebbe bene
solo punto-punto. Le collisioni sono risolte dall'hardware della sk
solo perche' sotto c'e' un collegamento elettrico e quando due di
questo trasmettono insieme sulla stessa linea "sballano" alcuni
parametri elettrici, in base a questa variazione e'  possibile
determinare che c'e' stata una collisione. Partendo dal presupposto
che dovremo usare un ricevitore in grado di capire se c'e' stata una
collisione "ottica", sara' necessario simulare una collisione
elettrica sul pezzo di collegamento attaccato alla sk ethernet
sperando che tutto funzioni esattamente come su un collegamento
coassiale (o a limite base T). 
Per quanto riguarda il discorso broadcast bisogna tenere conto che con
un collegamento strettamente ottico (anche se non laser) sara'
inevitabile avere un tipo di link point-to-point tra piu' host in
quanto non e' detto che due o piu' di essi stiano dentro lo stesso
lobo di irradiazione, a meno di non fare delle specie di sfere
tempestate di diodi PIN :D 
Cosa fattibile intesi ma forse un po' dispendiosa.
Ciao.
P.Trubini

In un articolo, 
in...@floating.com
 (Giuseppe Orofino)
stava parlando di [City Lan] La topologia? e ha scritto:
)Dobbiamo decidere il tipo di interfaccia prima di poter realizzare il tutto, la
)mia idea sarebbe di realizzare qualcosa di molto simile ad una rete ethernet
)questo ci semplificherebbe molto la vita per il semplice motivo che ha gia'
..
)Scarterei in partenza la seriale come interfaccia proprio perche' potremmmo
)realizzare solo dei link point-to-point, dovremmo implementare due apparati RTX
In ethernet il mezzo fisico si considera saturo quando raggiungi il 20-30%
della sua capacita` ? Cio` a causa delle collisioni.  E in ethernet rispetto
al nostro caso hai il vantaggio che tutti i computer sono in grado di sentire
se altri stanno trasmettendo, cosa non possibile nel nostro caso, perche`
tutti *non* vedono tutti.
ciao, Giuseppe
-- 
Giuseppe Zanetti

Lo sapevo mi avete preso per pazzo, rispondo prima a Giuseppe: se leggi bene i
ripetirori che ho denominato HUB servono proprio a trasportare i pacchetti di tutti i
clienti verso l'altro HUB, quindi di HUB in HUB in pratica tutta la rete si vede, per
semplificare il concetto pensa ad una lan aziendale dove c'e un HUB per piano, i PC
dei due piani non sono collegati fisicamente tra di loro ma si vedono tramite l'HUB.
Per Piergiorgio: sul coassiale hai ragione ma con l' RJ45 la collissione avviene credo
nel' HUB che ti ricordo ritrasmette  i pacchetti in broadcast a tutti quindi sempre se
ho ragione la mia teoria e' valisa.
Preparo dei disegni..............cosi' mi spiego


Scusate l'intromissione  ma in questo momento la struttuta iperstatica
per Scienze delle Costruzioni proprio non la riesco a risolvere.... mi
venite sempre in mente voi e questa idea della MAN a IR. :-)
Vedo che la discussione e' ferma alla realizzazione dei primi
transceiver e alla organizzazione della rete...
e qui incominciano a frullarmi delle idee ( che probabilmente sarranno
delle cagate... ma aspetto che me lo diciate voi :-) )
l'idea e' questa:
1) piazzare sul tetto di ogni utente1 ricevitore e 1trasmettirore IR
collegati tra loro con un cavo in modo che quello che ha ricevuto il
primo venga ritrasmesso dall'altro senza l'intervento del PC che
quindi puo' anche rimanere spento.... ( una specie di ripetitore....)
(l'utilizzatore numero N riceve dal'utente N-1 e ritrasmette a N+1)
2) realizzare in questo modo un anello chiuso di una decina di utenti
tra i vari tetti delle case , una sorta di "cella"  
3) collegare il PC in parallelo al cavo che passa i dati dal
ricevitore al trasmettitore...in modo che  quando il PC e' acceso
riconosca i pacchetti con il suo numero IP  e possa trasmetterne in
rete
4) Ogni 5 utenti un altra coppia di trasmettitore+ricevitore sul tetto
per interfacciarsi ad un altra "cella" di  computer....
 
             -------1----2-3--------------4      60-------------61
	    / |		      \    /	                  |
	   /  |		       \  /                       |
	      |		        5                       62       
                      |                                 / \
                      |                               /    \
                      10-9-----8---7------6      69--68-67-66
5) in ogni nodo ( per esempio il 5 in figura) fare in modo che a
computer spento i dati ricevuti da 4 vengano mandati a 60 e quelli
ricevuti da 69 a 6 senza nessun filtro ,praticamente creando una cella
piu' grande che parte da 1 e arriva a 10 passando anche per 60...69 ,
mentre a computer in 5 acceso questo filtri i pacchetti ricevuti da 4
senza inviare a 60 quelli inerenti alla cella da 6 a 10 ( eliminando
traffico quindi.... ) ( magari per questi nodi serve un UPS... )
In questo modo solo due utilizzatori ogni cella hanno l'onere di due
ricevitori e due trasmettirori sul tetto ( magari quelli piazzati
meglio all'interno dell citta' ) .... inoltre il tutto funzionerebbe
anche a comp. spenti.... e nessuno deve mettere una sfera di diodi da
1 Kw sul proprio tetto .-)
spero di non avere detto troppe bestialita'....
un saluto 			
					Max75

 wrote in message 37ce6f99...@news.supernews.com...
| On 1 Sep 1999 19:32:46 +0200, Tru...@OrsiWeb.Com (Trubini
| Piergiorgio) wrote:
| >Sono venuto a conoscenza del vostro progetto per un messaggio apparso in
un
| >NG
| Quale NG e quale messaggio?
| Mi interessa , devo capire se e come si sta diffondendo la cosa.
|
|
| >nella testa da qualche tempo pure a me. In passato utilizzavo il famoso
| >"baracchino" usando la 27 e dintorni, il mio sogno piu' grande sarebbe
stato
| Il baracchino:-) un peccato che abbia una banda tanto limitata.
| >quello di mettere insieme un baycom per una piccola rete locale,
purtroppo
|
| Rete locale e modem a 1200bps sono due concetti divergenti, credimi.
Certo, per "definizione" una LAN è su un supporto SICURO E VELOCE è per
questo che invece di chiamarla CityLAN sarebbe meglio trovare un nome un po'
migliore....
|
| >non avevo ne i mezzi ne le conoscenze adeguate, inoltre non trovavo
| >corrispondenti con cui condividere l'hobby.
| Questo e' triste ma vero. Anch'io prima della Rete avevo grosse
| difficolta' a trovare persone coi miei interessi.
|
| >Ad ogni modo mi piacerebbe capire alcune cose che non mi sono ancora
molto
| >chiare, soprattutto riguardo la topologia della rete che si vuole
| >implementare.
| Mi sto scervellando da settimane per trovare una topologia decente.
| Grosso modo ci sono, ormai. I problemi veri, pero' nascono dai
| dettagli.
|
Spiga... dai dai dicci
| >Personalmente ritengo che l'allacciamento ad internet sia un problema
| >secondario
|
| Capisco.
|
| >agli interessati in quel momento (questi basta che settino il default
| >gateway su quell'indirizzo).
| Ci ho pensato.
| Non sarebbe male un sistema automatico.
|
| >In  particolare mi piacerebbe comprendere meglio l'architettura della
rete,
| >per esempio come si vuole far interagire tre e piu' nodi con gli estremi
non
| La struttura della CL e' una specie di Internet in piccolo, per quanto
| riguarda la topologia.
|
| >adiacenti. Volete sfruttare un meccanismo simile al routing o ognuno dei
| >nodi deve necessariamente "vedere" *tutti* gli altri? Lo dico perche' qui
a
| Assolutamente: si va col routing, altrimente il carico diventerebbe
| troppo pesante.
|
| >quindi l'idea che mi ero abbozzato in testa era una specie di rete
cellulare
| In realta , ti dico, la mia idea non e' molto diversa tua.
| Il link IR per loro natura sono point-to-point: e' necessario per
| avere basse divergenze e fare lunghe distanze.
| Questo problema si scontra con la necessita' di dover comunicare con
| tre nodi allo stesso tempo, cosa che fa salire i costi.
| Sto appunto cercando un compromesso.
|
| >che non e' stato spedito direttamente a lui, procede ripetendolo in tx
(in
| >modo che faccia da ponte).  Una piccolo sistema per propagare i pacchetti
| Non solo: il round trip deve restare basso, per questo pensavo di
| implementare in hardware la cosa.
|
| >potrebbe essere raggiungibile da tutti e due i ripetitori ricevendo
quindi
| >il pacchetto due volte.
| Piuttosto uno dei casini che tento di eliminare e' la possibilita' di
| generare dei loop e delle tempeste di pacchetti.
|
| >Qui pero' si apre un interessante disquisizione mica da poco sul modello
di
| >tranceiver da utilizzare. Ottenere l'omidirezionalita' sarebbe l'ideale
per
| L'omnidirezionalita' si scontra con la necessita' di fare lunghe
| distanze.
| >una rete cittadina generica. Purtroppo con i sistemi ottici e' una
chimera.
| >Quindi come regolarsi per le possibili diramazioni della rete?
| Probabilmente bisognera' tirare fuori un sistema per le piccole
| distanze ma su angoli elevati.
| Piuttosto, se ho tre nodi che si appoggiano ad uno solo, e questi tre
| non si vedono, come possono sapere quando e' il loro tunro di
| trasmettere?
Semplicemente col problema della stazione esposta e stazione nascosta o come
diavolo si chiama.... guarda qui:  
http://space.tin.it/scienza/luiannel
praticamente con un protocollo a contesa... ma ne parlero' nel mio prossimo
mex ....
coming soon...
| E' questo il mio piu' grande problema e quello che sto cercando di
| risolvere in modo economico.
Don't warry... IrDA it' the solution!!!
|
| Nospam
|

 wrote in message
37ceae66...@172.31.0.129...
|
| Si puo' sempre sviluppare un serverino ad hoc e un protocollino sopra
| il tcp (o udp) che gestisca la registrazione e/o la ricerca di un nodo
| temporaneamente connesso.
Una cosa tipo ICQ...
 Una volta trovato basterebbe che
| riconfigurasse i parametri del tcpip (anche se dipende molto da come
| si intende sviluppare la rete: lan o internet (con la i minuscola)).
| A proposito, si intravvedono dei limiti per i messaggi broadcast?
non ti sto' seguendo...
cut...
|
| Con i router la cosa e' gia' stata risolta dalle specifiche del
| protocollo IP. Il famoso campo TTL (Time to Live) presente in ogni
| pacchetto IP serve proprio a questo scopo. Il suo valore ha la doppia
| valenza di contatore di hop massimi e di delay massimo in secondi in
| cui il pacchetto puo' rimanere in rete prima di raggiungere la
| destinazione. Quando un router riceve il pacchetto IP da
| un'interfaccia fa partire un timer, se il pacchetto rimane nelle code
| del router (perche' e' particolarmente intasato) per un tempo
| superiore al secondo allora il TTL viene decrementato di conseguenza
| altrimenti (comunque) viene decrementato di uno (ogni hop decrementa
| il TTL) in modo che se la rete fosse erroneamente configurata il
| pacchetto verrebbe killato al raggiungimento di un TTL=0, il sender si
| vedrebbe recapitare indietro un errore ICMP (TTL expired).  Oltretutto
| con utility come il ping e traceroute si puo' facilmente individuare
| il punto della rete che "inghiottisce" i pacchetti.
| Questo sarebbe un altro grosso vantaggio nel sfruttare una topologia
| internet-like, per fortuna il tcp-ip e' stato studiato proprio per
| essere trasportato su qualsiasi link di rete, sia esso wireless o
| dedicato, molte delle funzionalita' verrebbero a gratis.
esatto!!!
|
| >Piuttosto, se ho tre nodi che si appoggiano ad uno solo, e questi tre
| >non si vedono, come possono sapere quando e' il loro tunro di
| >trasmettere?
|
| Non mi e' molto chiaro, intendi che l'host centrale potrebbe avere
| solo un interfaccia per gestire piu' nodi adiacenti?
penso di aver capito di si'
Quindi potrebbe
| ricevere i pacchetti contemporaneamente sullo stesso receiver?
si' generando una collisione
| Questo in effetti e' un problema. Credo che debba essere risolto dal
| protocollo di datalink (non so come viene gestita la cosa con IrDA, ma
| suppongo che sia contemplata),
CERTAMENTE E IN MODO EFFIENTISSIMO...
 comunque la stessa cosa si presenta nei
| link radioamatoriali su tcp-ip (piu' stazioni condividono la stessa
| risorsa, nel caso, la frequenza) pero' qui inizio a saperne veramente
| poco, so che si usa l'AX.25.
Bhe.. con  l'AX.25  le cose funzionano non troppo velocemente...  e fai
conto che il TCP/IP è incapsulato in un pacchetto Ax.25 e quindi non
partecipa alla gestione del flusso.
| Comunque in genere il ricevitore si accorge della sovrapposizione e
| scarta il pacchetto (o genera un nak?),
con l'ax25 genera un nak
 i nodi che hanno causato la
| collisione dovrebbero ritrasmettere facendo pero' partire un timer di
| valore differente, se si ripresenta di nuovo una collissione (questa
| volta con un altro host) la cosa si ripete. Un po' come su ethernet.
|
La cosa funge così: viene generato un numero casuale... dopo che è trascorso
il tempo indiviudato moltiplicando questo numero casuale per una costante di
tempo viene ripetuto il pacchetto... in caso di una nuova collisione la
costante di tempo viene eleavata esponenzialmente e si ripete il tutto
finchè il pacchetto non viene trasmetto correttamente.
--
---
Alberto Gorni
Via E. Da Pozzo 39/15
16133  Genova GE
Italy
Cell: 
+39 347 5147196
E-mail 
san...@tiscalinet.it
Fast E-mail 
03475...@mail.omnitel.it
Se vuoi che venga avvisato immediatamente della Tua E-mail mandala anche al
secondo indirizzo.

giusta strada pero' fatemi sapere
Potrebbe andare.
Ho due perplessita'.
La prima e' sul brodacast su un grande angolo solido.
Questo riduce molto la distanza massima.
La seconda e' sul costo dell'interfaccia tra ethernet e IR.
Nospam

poco, so che si usa l'AX.25. 
Era proprio pensando a questo che mi sono preoccupato.
L' IrDA attraverso la seriale e' tipicamente point-to-point.
Io voglio sfuttare un intefaccia comune  (=> economica) per far 
sembrare tutto come un segmento di ethernet.(sorry per il casino)
La stessa cosa che fa il flexnet su win95 o il JNOS su DOS con i modem
radioamatoriali.
Nospam



necessaria, se non altro per i nodi piu' importanti.
Oltretutto win9x *non* e' stato proprio progettato per questo tipo di
scopi, a limite (per il routing) si puo' gia' fare qualcosa di piu'
con Windows NT, ci sono pero' notevoli "contro" tra i quali: NT costa
soldi, e' pesantissimo rispetto a linux, non mi pare che IrDA sia
gestita e in generale, nel mondo windows, reperire informazioni
(soprattutto per scrivere driver e moduli di basso livello) e'
estremamente difficoltoso (la gente che orbita intorno a Micro$oft
vuol fare soldi anche sulle informazioni acquisite con l'esperienza,
l'ho sperimentato di persona). Tenuto conto di questi fattori bisogna
comprendere fino a che punto l'architettura della CL risulti
vincolante. Infatti ritengo che per fornire il servizio a tutti
bisognera' pensare in modo tale che *qualsiasi* nodo della rete possa
diventare facilmente un hub invece di essere (e rimanere) un semplice
downlink secondario, anche perche' si potrebbe voler aggiungere un
host che per forza di cose risulti visibile solo da uno specifico nodo
di downlink. Quindi a mio avviso sara' necessario avere una macchina
dedicata alla gestione della CL che rimanga _possibilmente_ sempre
accesa. Win9x non si presta ad essere un server di rete (per svariati
motivi, tra i quali la stabilita' e le richieste di risorse per "cazzi
e lazzi" che mai un server di rete andra' ad usare) , correggetemi se
sbaglio ma la scelta piu' razionale rimane Linux. 
Mettiamoci anche la moltitudine di sperimentazioni  implementate
sfruttando questo s.o. che ci potrebbero essere molto utili e il gioco
e' fatto.
E' cmq sempre possibile che ci sia un driver che faccia vedere irda
come un device di rete e permetta a win98 di effettuare il bind su di
essa. Se c'e' 99/100 si paga e non e' detto che i sorgenti siano
liberi per eventuali (e forse inevitabili) modifiche che ci potrebbero
servire.
Concludendo, ritengo che usare Linux non sia affatto una scelta
restrittiva per l'utente generico, mentre concentrarsi su windows lo
sara' sicuramente per lo sviluppo della rete stessa. Si tratta di fare
una scelta.
P.S.
Con questo non vorrei essere frainteso, non voglio assolutamente
forzare la gente ad usare linux ma questa a mio avviso e' la
situazione.
Inoltre mi pare di aver capito che questo progetto sia "OPEN" (anche
se non conosco i dettagli) e allora perche' non premiare
un'architettura nata totalmente sulla base di questa filosofia invece
di andare a fasciarsi la testa con un mondo contrario allo sviluppo di
tecnologie aperte e standard come invece e' Windows? Ricordate i
documenti "Halloween"?
Pensateci.
Ciao

tutti *non* vedono tutti.
Si e' corretto, ma come pensi di gestire le collisioni ottiche? 
Ci sono dei problemi teorici inevitabili tra i quali quello delle
stazioni esposte e nascoste, cosa evidentemente non presente su
ethernet (sia essa coassiale o con hub o con switch). Ci avevo pensato
anch'io alla ethernet per avere tutto lo stack software sopra gia'
implementato e funzionante ma non avevo trovato soluzioni
soddisfacenti, a meno di un collegamento punto punto con solo due sk.
Se hai qualche intuizione dimmelo che sono interessato! :)
Ciao
P.Trubini

documenti "Halloween"?
In compenso gli standard imposti dalla NSA (che e' *potente*) li
accettano, non se sia vero, ma hai letto della NSA Key?
Non mi stupirei se fosse vero.
Nospam

In un articolo, 
trubini@nospam_orsiweb.com
 (Piergiorgio Trubini)
stava parlando di [City Lan] La topologia? e ha scritto:
)On 3 Sep 1999 10:10:41 +0200, in it.comp.reti.wireless you wrote:
)
)>In ethernet il mezzo fisico si considera saturo quando raggiungi il 20-30%
)>della sua capacita` ? Cio` a causa delle collisioni.  E in ethernet rispetto
)>al nostro caso hai il vantaggio che tutti i computer sono in grado di sentire
)>se altri stanno trasmettendo, cosa non possibile nel nostro caso, perche`
)>tutti *non* vedono tutti.
)
)Si e' corretto, ma come pensi di gestire le collisioni ottiche? 
)Ci sono dei problemi teorici inevitabili tra i quali quello delle
)stazioni esposte e nascoste, cosa evidentemente non presente su
)ethernet (sia essa coassiale o con hub o con switch). Ci avevo pensato
)anch'io alla ethernet per avere tutto lo stack software sopra gia'
)implementato e funzionante ma non avevo trovato soluzioni
)soddisfacenti, a meno di un collegamento punto punto con solo due sk.
)Se hai qualche intuizione dimmelo che sono interessato! :)
Guarda che stavo anch'io remando contro a questa ipotesi :-)
Giuseppe
-- 
Giuseppe Zanetti

diavolo si chiama.... guarda qui:  
http://space.tin.it/scienza/luiannel
OK, gli do uno sguardo.
Nospam

e qui incominciano a frullarmi delle idee ( che probabilmente sarranno
La struttura ad anello e' molto interessante.
Sto cercando di svilupparla.
Nospam

 wrote in message
cut...
| )Ci sono dei problemi teorici inevitabili tra i quali quello delle
| )stazioni esposte e nascoste, cosa evidentemente non presente su
| )ethernet (sia essa coassiale o con hub o con switch). Ci avevo pensato
cut...
Ecco come cazzo si chiamava ...  stazione esposta e nascosta... bene
nel'IrDA è IMPLEMENTATO un protocollo a divisione di risorsa con un
controllo anche su questo...


documenti "Halloween"?
E' da un po che lurkavo tutto il NG leggendo quello che si diceva; ma
adesso mi sembra di dover dire la mia su questro thread.
Volevo far notare che quasi tutti quelli che stanno collaborando su
questo progetto hanno una postazione linux (io compreso); in oltre
volevo sottolineare il fine (per adesso) solo sperimentale del
progetto...
Quindi io arrivo a queste conclusioni: dato che sviluppare un driver
per questo sistema e' molto piu' facile su postazioni linux che non
win, perche' non cominciare con questi; quando verdemo che il progetto
e' funzionante e pronto per un uso piu' di massa potremo contattare
qulche esperto nei NGs di windows e chiedere qualche consiglio sullo
sviluppo per windows.
Penso che nessun appassionato di win rinuncera' ad aiutarci e a
vornirci le informazioni necessarie, sapendo che il progetto funziona
e non e' una teoria!
Che ne dite?

questo progetto hanno una postazione linux (io compreso); in oltre
Giustamente fai notare che per ora possiamo usare solo linux.
In ogni caso bisogna almeno capire se sia fattibile trasportare tutto
sotto Windoze per non ritrovarsi con un sistema limitato a pochi
linuxiani.
Fosse per me userei solo linux, ma il fatto e' che la densita' di
linuxiani/Km^2 non e' molto alta in italia, specialmente fuori Milano.
Disgraziatamente serve qualcuno con windoze che faccia, se non altro,
da relay.
Sul resto hai ragione. Non ho molto da aggiungere.


Ha un solo limite: la banda disponibile e' un quinto della larghezza di
banda totale.
In ogni caso secondo me e' l'unica soluzione ragionevole. 
Ciao Davide.
Ps.: un buongiorno a tutti.
----

banda totale.
Se veramente si riuscisse a fare andare le schede IRDA a 1 megabit al
secondo , 1000/5 = 200 kbit -> 200/8 = 25 Kbyte al secondo !!! 
per me e' gia' molto buono.
Comunque penso che sia un idea che si possa migliorare magari
assegnando dinamicamente la banda passante...
un saluto
				Max75

Tempo fa avevos scitto un articolo e pensavo che su questo argomento non ci
saremmo ritornati. Vediamo di mettere ordine:
1) Una rete è formata da una serie di server SEMPRE accesi e da una serie di
PC che si collegano quando l' utente vuole usare la rete e questi PC sono
spenti quando l' utente ha finito di usare il PC
2) Un sever DEVE essere amministrabile da remoto; è IMPENSABILE dover andare
fisicamente dove si
trova un server, attaccarci la tastiera, il monitor, il mouse e fare le cose
che vanno fatte.
3) Un PC che fa da cient se non funziona non importa a nessuno la rete
continua a funzionare al 100% è
solo l' utente di quel pc che deve provvedere a farlo funzionare ma se non
ci riesce sono cazzi suoi.
4)Ognuno può scegliersi come sistema operativo del proprio client quello che
preferisce. Se volete usare windows usatelo, se voleto usare MacOS fatelo se
poi formattate 2 volte al mese e vi si pianta il PC
meglio, almeno liberate la banda.
5)I server devono essere formati dal minor numero di pezzi possibili
(provate a vedere quanto assorbono i
vari componenti: pure la ram consuma corrente e anche il disco che gira (e
sotto windows gira molto).
ci sono altri 1000 punti del genere, non me li fate scrivere tutti.
Ho alcune domande.
1) io metto il server sotto il tetto: chi viene a casa mia quando devo fare
qualche lavoro sul server a
portare il monito sul tetto????? preferisco fare un telnet dal mio pc sulla
scrivania
2) chi ha volgia di fare un backup di qualche giga su un server NT???? a me
bastano pochi mega per linux
3)Chi paga i sistemi operativi???? stiamo limando le cento lire e qui voleto
pagare tutte le licenze per i server????? Guardate che io NON intendo
installare un bit di software che sia da pagare: se voi a casa vostra usate
NT sappiate che se lo avete copiato è bene che ci pensiate prima di dire
male di Linux
Ho alcune considerazioni
1) Forse non avete capito (mi riferisco a quelli che VOGLIONO usare NT o
addirittura , questa poi e cominca, winsows98, un tipo poi aveva proposto
windows311!!!!!)ma gli utenti della rete non devono preoccuparsi
di gestire i server Linux, non devono nemmeno mettere un server a casa loro,
loro continuano ad usare solo il loro PC con qualsiasi sistema operativo,
poi i server li amministrano un po' di gente (quelli che si offrono) ma gli
utenti nemmeno si accorgono di nulla, se i server usano Linux, Free BSD,
Solaris o qualsiasi altra cosa
a loro deve solo interessare che funzionino.
2)Gradieri che a questa discussione partecipassero solo coloro che hanno
usato Linux e windows (e li conoscono bene), chi usa windows e basta e non
ha MAI amministrato una rete è bene che pensi a come far andare i moduli IR
sotto windows e lasci stare i server. I server sono una cosa seria e devono
andare, se per
caso metto NT sul server e poi mi si pianta io lo butto dal tetto, con tutti
i moduli ir attaccati, poi lo prendo a
martellate.
3) insomma (e lo dico per chi cotinua a sostenere windows) non venite a
rompere con questa storia che la gente usa windows e lo preferisce: non me
ne frega nulla. Usatelo voi, come cliente (a me va benissimo). Io non vi
vengo a dire installate linux sui vostri clinet, io vi dico usate quello che
volete, ma non capisco cosa vi interessi dei server: Bill Gates vi paga per
scrivere queste mail? Se è si fate bene, almeno guadagnate, altrimenti che
ve ne frega!
4) Volete una rete che funzioni, volete che i dati non si perdano??? Fateci
fare i server come meglio crediamo, io ho molta esperienza e sostengo linux
al 100%
5) Per quanto mi riguarda l' uso di linux per i server è una certezza, non
c'e' alternativa , uno perchè linux è una bomba, 2 perchè le alternative
fanno schifo.
In conclusione: Linux non è in discussione!!!!! Chi continua a sostenere il
contrario non ha mai amministrato una rete dove gli utenti rompono le
scatole ogni volta che c'e' un problema e si infuriano come gatti quando
perdono dei dati.
                                        gabriele zucchetta
MO AVETE CAPITO?
p.s. gradirei nessuna risposta. Per favore!

ne frega nulla. Usatelo voi, come cliente (a me va benissimo). Io non vi
Concordo con te, ma come vedi, per ora non ho molta scelta.
A meno che non riesca a far girare la roba che interessa al mio amico
anche sotto Linux, il quale , magari va da floppy.
Ah, la suddetta applicazione e' Quake II :-)) , in futuro sara' Quake
III Arena:-)))).
Nota la volgarita' di queste motivazioni:-).
Nospam