Newsgroup: it.comp.reti.ip-admin
Titolo: Header : tipo di servizio.

Nonostante l' RFC760 e qualche articolo su rivista non sono ancora 
riuscito a capire una cosa...
A quanto ho capito il campo "tipo di servizio" e' formato da 8 bit:
3 bit legati alla priorita' del mex con valori chiaramente da 0 a 7
3 bit legati rispettivamente a ritardo, capacita' e affidabilita'
e gli altri due ? Non sono implementati ??
Seconda curiosita' la priorita' settabile per il trasporto delle e-mail
quali valori assume ? 0=bassa 1=normale 3=alta oppure e' spostata su 
nella scala  tipo 3=bassa 4=normale 5=alta ...
Facendo alcune prove in locale ho visto che Netscape ha 5 livelli di
priorita' che vanno da 1 (la piu' alta) a 5 (la piu' bassa). Ma non 
dovrebbe  essere 000 = 0 la piu' bassa e 111= 7 la piu' elevata ?
Come mai la scala e' invertita? Oppure il valore viene ribaltato
quando e' trasformato in binario ?
Mi piacerebbe sapere dove IE, che ha solo 3 livelli di priorita', fa
partire la sua scala delle priorita'... 
Sono curioso di sapere se M$ e Netscape hanno utilizzato un meccanismo che
doveva originariamente servire a garantire una maggiore priorita' ai 
datagram di controllo per la rete, per altri servizi alle volte un 
pochetto abusati.
Come vedete ho le idee un po confuse :-) 
Grazie in anticipo.
L o r D

 pochetto abusati.
Non e' queso il caso. Possiamo, se vogliamo, stare delle settimane a
parlare di questo genere di cose, ma stavolta sono "innocenti" :)
Ciao
Lele

 X-Priority: 1
 
E' questo il punto della cantonata .. (e si che un paio di X- li ho
aggiunti anch'io a sendmail).. non ho neppure visto di striscio le
X- del campo Priority. Erroneamente pensavo che il campo fosse
standard e che andasse a modificare il valore della Precedence.
Solo ora mi accorgo che e' un campo propietario ;) ops...
Ok ti ringrazio a vado a spulciare gli RFC di cui sopra.
-- 
Ciao
L o r D

 risentire di informazioni provenienti dal livello superiore.
Ammesso che abbia capito bene, se cosi fosse non si protrebbe fornire
nessuna informazione allo strato sottostante, nemmeno quelle necessarie a
costruire l'header locale. Se dai un occhiata all'header IP ad esempio
vedi che ci sono almeno 4 informazioni (i due indirizzi, il TTL, appunto
il TOS e le eventuali opzioni) che devono necessariamente arrivare dal (e
in ricezione essere passati al) transport layer. Non solo, ma quest'ultimo
scambia le medesime informazioni aggiunte ad altre con l'applicazione.
Il fatto che l'header venga generato localmente non implica che lo strato
corrente non possa utilizzare delle informazioni presenti nell'header di
livello superiore oppure ottenute in altro modo ma sempre provenienti
dall'alto. 
L'RFC1122 (Braden, "Requirement for Internet hosts") dice, sempre a
proposito del TOS:
	      --------		
                 The TOS field may also be mapped into link-layer 
                 service selectors.  This has been applied to provide
                 effective sharing of serial lines by different classes
                 of TCP traffic, for example.
              ---------
questo sposta il problema addirittura di uno strato piu' in basso. Una
infomazione generata direttamente dall'applicazione, modifica delle
livello di link.
Lo stesso RFC specifica tra i requisiti di un host, il fatto che possegga
un meccanismo per cui le informazioni di cui parlavo (ttl e tos) possano
venir stabilite e ricevute dall'applicazione.
Il tutto ovviamente IHMO.
Ciao
Lele